[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture

On Thu, 17 Oct 2019 11:45:12 +0300, Niko Tyni wrote:

> > > Yes, this means updating hundreds of packages and I don't expect that
> > > this is completed in time for bullseye. If you start working on this,
> > > prefer working on packages with few dependencies (likely no
> > > libsomething-perl dependencies).
> > If we have a clear and scriptable pattern I think we can get very far
> > with uploading those 500 arch:any packages. But we'll see.
> I note that this will result in source packages that are not trivially
> rebuildable in stable, as perl-xs-dev is not available there. Is that
> a concern?

Right, that thought crossed my mind today as well.
The question is: how often do we really backport packages, and is
dropping perl-xs-dev too much of a burden? (My answer would be
"rarely" and "not really".)
> ISTR pkg-perl delaying build dependencies on the latest debhelper in
> the past for the same reason. I think backports helped that a bit, but
> backports is not an option for perl-xs-dev (as they only accept packages
> matching what is currently in testing.)

I'm not sure … I think we never had a clear policy of updating
debhelper version/compat level, it were more traditions which also
seem to have changed over time.
My memory is that we mostly were reluctant on bumping version/compat
level when the change had zero effect on perl packages. Recently it
was more like that we updated dh-make-perl quickly and that people
also got into the habit of bumping debhelper version/compat level
soon when updating packages.

(which is probably outdated by now) has a bit of the history; more is
in the git log :), about which baseline at which time and which
version for which feature).
> I suppose we could try pushing libperl5.28 Provides: perl-xs-dev
> as a stable update, but it would have the same versioning concerns on
> upgrades with multiple packages satisfying the build dependency. And I
> doubt SRM accepts stable updates adding new binary packages.

Ack, and IMO it's not worth the effort.


 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: U2: Gone (New Mix)

Attachment: signature.asc
Description: Digital Signature

Reply to: