Perl Modules Conundrum

[Scott Kitterman]

On Wednesday 09 January 2008 02:44, Martin Pitt wrote:
> Hello,
>
> Scott Kitterman [2008-01-07 11:41 -0500]:
> > Currently there are Perl modules (at least libfile-temp-perl and
> > libtest-harness-perl) that are provided by the perl-modules package in
> > Perl and also packaged separately in a later version.  It is currently
> > impossible to build against these separate packages on the buildds.
> >
> > What happens is that sbuild checks to see if it has such a module
> > installed, determines that it does, because the module is provided by
> > perl-modules. Later the build will fail due to dependency problems
> > because the version is insufficient.
>
> Right, and this is a bug we should fix, since it does not just affect
> Perl. If sbuild sees a versioned dependency, it should not look for
> already available Provides: since these are not versioned. Since this
> does not seem to affect Debian's sbuild, I guess this problem comes
> from our Ubuntu specific changes to build dependency installation
> (which has been tweaked particularly for alternatives IIRC, to avoid
> small b-dep only deltas to Debian). Adam, what do you think?

Adam and I discussed this on IRC yesterday and IIRC, he thinks he can fix it 
relatively quickly.  As Ming Hua observed in his message that packages I've 
noticed with this problem are all Arch:All so the wouldn't have had a 
sourceful upload in Debian.

> > The challenge is that provides are versioned, so there's no way for
> > sbuild to know with it's current design that it should look further.  I
> > suspect it's unrealistic to except a near-term Launchpad/sbuild fix for
> > this.
>
> I disagree. Since Provides: can never be versioned, a versioned b-dep
> can never be fulfilled by a virtual package, so at least conceptually
> this is easy to solve (no idea about the code, though).

Hopefully Adam will get it nailed in short order.

> > My proposed solution to this problem is to rip libfile-temp-perl and
> > libtest-harness-perl out of perl-modules, promote the separate packages
> > to Main, and then add them as dependencies of perl-modules to that they
> > could still be relied on to be present.
>
> That would be possible, but I'd actually prefer to properly fix
> sbuild. My second-best preference is to update perl's included modules
> themselves (upstream preferably) and get rid of the duplicate packages
> entirely. Only if that doesn't work out, we can make them strict
> dependencies of perl-modules.

Syncing Perl 5.10 from Debian Experimental would also solve this particular 
problem and the versions in that package are all sufficient for the packages 
currently at issue.  Of course that may cause other problems ....

Given that it appears there may be an sbuild fix on the horizon, I'll put this 
on hold for now.  I've still need to get the separate package for 
libfile-temp-perl promoted to support the ubuntu-server spec for amavisd-new, 
but that shouldn't need any further discussion here.

Thanks,

Scott K