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

Re: Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1


Dimitri John Ledkov <xnox@debian.org> (2018-04-20):
> From my point of view, this is confusing... cause I regard myself as
> being part of the installer team myself.
> I guess you are advocating for general code review, more than two
> pairs of eyes on things?

There were no mails on debian-boot@, so that addition wasn't announced
nor coordinated.

> > I'm not sure why stashing a -V there once and for all to be
> > future-proof wouldn't be adequate or desireable. People can argue
> > all they like about whether the package is RC buggy in this specific
> > revision, but it seems rather pointless, I really do care about
> > mid/long-term maintenance. I have enough on my plate to not want to
> > monitor such packages closely, and open a specific bug report in
> > their next revision…
> In absolute terms, it simply isn't, for debs. And only marginally
> better for udebs.

If that wasn't clear from the context: I'm interested in udebs
specifically, and while I'm going to have to disagree with “marginally
better”, that would still be a net win when the cost is zero.

> The pain is specifically with pulling udeb builds of packages that
> were done against newer glibc (e.g. in sid) into d-i that is based on
> stable/testing. Whilst the builds of those packages do not require
> newer glibc, they gain an artificially high dependency on glibc from
> sid.

That looks like d-i 101: having a consistent set of packages within a
given suite is the best way to avoid issues.

> > Are you volunteering to introduce separate symbols support for udebs
> > to all the required components and to maintain it over time?
> I see that there might be a mapping issue between deb library names
> and udeb library names. And i'm hoping a simple extension of the
> .symbols file syntax should make it all work fine.

It seems like not liking -V (again, only used by udebs when symbols
files are present for debs) doesn't look like a good reason to get more
complexity in the symbols handling…

The upload we're talking about (that I only quickly glanced at) actually
bumped the version of all symbols to the last version, meaning it
actually mimicked having passed the horrendous -V flag! I'm not sure how
a symbols syntax extension would have helped get the basics straight…

> > I'm not sure what the issue is with talking to the debian installer
> > team when you're touching udeb packages and trusting their
> > assessment?
> The issue being, is that I regard myself as being part of the debian
> installer team..... I am delusional?
> Unless what you are in fact saying is actually "talk to Kibi".

As I think I've mentioned already, the bare minimum is mailing
debian-boot@, which didn't happen. And yes, bonus points if I'm in cc
(that's really appreciated); people would usually loop me in if I'm late
to the party (which happens after the fact when people mentioned the
package was sitting in NEW); and if I miss mails on debian-boot@ because
I'm lagging behind, fault's on me.

> -V a must for udebs would be bad, as that will never generate correct
> dependencies. It at best can only set an inflated minimum version,
> without a correct upper bound.

I'm not sure what the problem with that is.

Yes, sometimes udebs need to wait for other packages to migrate
together because of that “inflated” version. But usually I'm the one
reviewing those issues and adding age-days/urgent hints as needed on the
release team side, when a bunch of packages are wanted in the next d-i

> symbols support should be there for udebs

But it's not.

> and -V should just die.

It's served us (or at least me) for many years, so I'll keep on relying
on it, sorry if that's so irritating.

Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature

Reply to: