Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1092666 > unrolled thread

Bug#1003176: transition: perl 5.34

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1003176: transition: perl 5.34 Alex <gaaf@gmx.net> - 2022-02-10 13:40 +0100
    Bug#1003176: transition: perl 5.34 Paul Gevers <elbrus@debian.org> - 2022-02-10 15:10 +0100
      Bug#1003176: transition: perl 5.34 Alex <gaaf@gmx.net> - 2022-02-10 15:30 +0100
        Bug#1003176: transition: perl 5.34 Sebastian Ramacher <sramacher@debian.org> - 2022-02-10 17:10 +0100

#1092666 — Bug#1003176: transition: perl 5.34

Hi,

I was wondering why the condition for the perl-5.34 transition has the
"depends" in the condition, but not the "recommends"?

The "collectd" package recommends libperl5.34 as it has a loadable
module built against libperl5.34. The transition criteria however will
not consider rebuilding the package even though in the current state in
unstable it is broken for any practical usage. The module still loads,
as libperl5.32 is still present, but the executed perl code fails on
lots of missing packages as their 5.32 version is already replaced with
the 5.34 version.

Please consider adding "recommends ~ libper5.34" to the transition
criteria.
--
mvg,

Alex Hermann

[toc] | [next] | [standalone]

#1092676

[Multipart message — attachments visible in raw view] — view raw

Hi Alex,

On 10-02-2022 13:21, Alex wrote:
> I was wondering why the condition for the perl-5.34 transition has the
> "depends" in the condition, but not the "recommends"?

I think because we never did that in the past, I *assume* the tracker 
was based on the previous one.

> The "collectd" package recommends libperl5.34 as it has a loadable
> module built against libperl5.34. The transition criteria however will
> not consider rebuilding the package even though in the current state in
> unstable it is broken for any practical usage. The module still loads,
> as libperl5.32 is still present, but the executed perl code fails on
> lots of missing packages as their 5.32 version is already replaced with
> the 5.34 version.

Hmm, I *think* libperl* is co-installable on purpose, so if stuff 
breaks, is it because you expect more than you ask for or because you 
also link against other packages that link against the latest version 
and you get symbols double (I am not sure if I use the right 
terminology, but I hope you understand what I mean)? Do you know?

> Please consider adding "recommends ~ libper5.34" to the transition
> criteria.

For now, I'll leave this call to Sebastian.

Paul

[toc] | [prev] | [next] | [standalone]

#1092680

On donderdag 10 februari 2022 14:59:59 CET Paul Gevers wrote:
> > The "collectd" package recommends libperl5.34 as it has a loadable
> > module built against libperl5.34. The transition criteria however
> > will not consider rebuilding the package even though in the
> > current state in unstable it is broken for any practical usage. The
> > module still loads, as libperl5.32 is still present, but the
> > executed perl code fails on lots of missing packages as their 5.32
> > version is already replaced with the 5.34 version.
>
>
> Hmm, I *think* libperl* is co-installable on purpose,

Probably, but that's only useful if the perl script doesn't use any
modules with compiled code.



> so if stuff
> breaks, is it because you expect more than you ask for or because you
> also link against other packages that link against the latest
> version and you get symbols double

I'm not compiling anything, just trying to run a script which uses
"HTML::Parser" via an embedded perl interpreter in collectd.



> (I am not sure if I use the right
> terminology, but I hope you understand what I mean)? Do you know?

I don't think I do, unfortunately.


Because the collectd perl plugin is linked against libperl5.32, my
script fails as libhtml-parser-perl is already upgraded to 5.34.

I agree that package dependencies probably won't be able to solve this,
but that's not the message I'm trying to convey.

The issue is that in order for my script to work again, I must wait
until collectd is recompiled against libperl5.34. Because of the
criteria/conditions in the transition, this won't happen automatically
as collectd only has a recommends against libperl5.32, not a depends.

I think in case of a recommends on a _library_, it is warranted to
trigger a rebuild too, as recommends on libraries mostly implies that it
will be dl-opened instead of linked. And dl-opended libraries have the
same versioning constraints as directly linked ones.

Hence my request to add "recommends ~ libperl5.43" to the transition
criteria.
--
mvg,

Alex Hermann

[toc] | [prev] | [next] | [standalone]

#1092686

On 2022-02-10 15:19:57, Alex wrote:
> On donderdag 10 februari 2022 14:59:59 CET Paul Gevers wrote:
> > > The "collectd" package recommends libperl5.34 as it has a loadable
> > > module built against libperl5.34. The transition criteria however
> > > will not consider rebuilding the package even though in the
> > > current state in unstable it is broken for any practical usage. The
> > > module still loads, as libperl5.32 is still present, but the
> > > executed perl code fails on lots of missing packages as their 5.32
> > > version is already replaced with the 5.34 version.
> >
> >
> > Hmm, I *think* libperl* is co-installable on purpose,
> 
> Probably, but that's only useful if the perl script doesn't use any
> modules with compiled code.
> 
> 
> 
> > so if stuff
> > breaks, is it because you expect more than you ask for or because you
> > also link against other packages that link against the latest
> > version and you get symbols double
> 
> I'm not compiling anything, just trying to run a script which uses
> "HTML::Parser" via an embedded perl interpreter in collectd.
> 
> 
> 
> > (I am not sure if I use the right
> > terminology, but I hope you understand what I mean)? Do you know?
> 
> I don't think I do, unfortunately.
> 
> 
> Because the collectd perl plugin is linked against libperl5.32, my
> script fails as libhtml-parser-perl is already upgraded to 5.34.
> 
> I agree that package dependencies probably won't be able to solve this,
> but that's not the message I'm trying to convey.
> 
> The issue is that in order for my script to work again, I must wait
> until collectd is recompiled against libperl5.34. Because of the
> criteria/conditions in the transition, this won't happen automatically
> as collectd only has a recommends against libperl5.32, not a depends.
> 
> I think in case of a recommends on a _library_, it is warranted to
> trigger a rebuild too, as recommends on libraries mostly implies that it
> will be dl-opened instead of linked. And dl-opended libraries have the
> same versioning constraints as directly linked ones.
> 
> Hence my request to add "recommends ~ libperl5.43" to the transition
> criteria.

The tracker is mostly a copy of trackers that we used for other perl
transitions. I don't remember Packages that only recommend libperlX
being a problem for perl transitions.

The tracker now also checks for recommends and I have binNMUed collectd.

Cheers

> --
> mvg,
> 
> Alex Hermann
> 

-- 
Sebastian Ramacher

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web