Bug#914897: debating the wrong thing
Svante Signell dijo [Wed, Dec 05, 2018 at 02:03:19PM +0100]: > > If we keep merged-/usr as default then we can /recommend/ people to > > install usrmerge to switch to merged-/usr; reducing the difference > > between newly-installed and existing setups is a good idea IMHO. I > > think I filed a report for this two years ago. > > > > Maybe we should also mention somewhere that it might be useful to not > > switch build environments (yet). > > How about this case: > > - Make as default non merged-/usr for all buildds. > - Make a choice of non merged-/usr or merged-/usr in the installer. > - Users wanting merged-/usr install the usrmerge package and convert to > merged- > /usr. > > - We have two alternatives here: > 1) For those not wanting merged-/usr: >All is fine. > > 2) For those having merged-/usr installed: >Re-run usrmerge to convert all newly installed packages to merged-/usr. >Is this possible or is installing that package a install-once-only? AFAICT, this would mostly cover the issues, at least as far as I understand them. There is still one extra point: Computers used by Debian contributors to build their packages on. If I build my package on a merged-/usr system, it might end up breaking in non-merged systems. Throwaway binary uploads seems like a safe bet for this issue. Now - Are we ready to do it? signature.asc Description: PGP signature
Bug#914897: debating the wrong thing
On Tue, 2018-12-04 at 21:58 +0100, Ansgar Burchardt wrote: > > If we keep merged-/usr as default then we can /recommend/ people to > install usrmerge to switch to merged-/usr; reducing the difference > between newly-installed and existing setups is a good idea IMHO. I > think I filed a report for this two years ago. > > Maybe we should also mention somewhere that it might be useful to not > switch build environments (yet). How about this case: - Make as default non merged-/usr for all buildds. - Make a choice of non merged-/usr or merged-/usr in the installer. - Users wanting merged-/usr install the usrmerge package and convert to merged- /usr. - We have two alternatives here: 1) For those not wanting merged-/usr: All is fine. 2) For those having merged-/usr installed: Re-run usrmerge to convert all newly installed packages to merged-/usr. Is this possible or is installing that package a install-once-only? Just a thought!
Bug#914897: we do have a complete archive rebuild for buster and sid amd64 (Re: Bug#914897: debating the wrong thing)
On Tue, Dec 04, 2018 at 09:58:09PM +0100, Ansgar Burchardt wrote: > > We later learned only a part of the archive got rebuilt since the bad > > debootstrap backport. > Yes, some packages were not yet rebuilt in testing, but having them > rebuilt in unstable is enough. looking at https://tests.reproducible-builds.org/debian/index_performance.html and specifically at https://tests.reproducible-builds.org/debian/unstable/amd64/stats_builds_age.png and https://tests.reproducible-builds.org/debian/buster/amd64/stats_builds_age.png it seems that all of unstable and buster has been rebuild on amd64 since we enabled these tests (around Nov 9th). Looking more specifically at https://tests.reproducible-builds.org/debian/index_amd64_oldies.html it actually seems like the amd64 buster rebuild (testing usrmerge diffs) will only be completed in 24h or so ;) arm64 will be done soon as well, armhf will take a bit more time and i386 some more. If you only want to look at one url, look at the last one above, index_oldies... -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#914897: debating the wrong thing
Adam Borowski writes: > On Tue, Dec 04, 2018 at 06:48:45PM +0100, Ansgar Burchardt wrote: >> In very rare cases (an estimated 0.3% of the archive or so). I'm fairly >> confident that for more than 0.3% of the archive something can go wrong >> when building in non-clean environments. > > Your figure of ~80 packages counts only packages which went through a > reproducible-builds rebuild. So only all? > We later learned only a part of the archive got rebuilt since the bad > debootstrap backport. Yes, some packages were not yet rebuilt in testing, but having them rebuilt in unstable is enough. >> We had the discussion (usrmerge as default) already quite some time >> ago. Why start again at zero? As a random reference, the D-I Stretch >> RC 1 release announcement explicitly stated: >> >> +--- >> | * The switch to merged-/usr as the default setting for debootstrap >> |was reverted since it uncovered a number of important issues which >> |might not be all fixed in time for stretch. This setting is >> |expected to come back as the default at the beginning of the next >> |release cycle. >> +--- >> >> And just that happened (except a bit later). > > Except that the change went live only on 2018-11-10, then waited until > buildds recreated their chroots, then until dinstall and mirror push... No, anyone using testing/unstable to setup a new build chroot since June should have gotten a merged-/usr chroot. That no issues were found earlier is probably related to there being not so many issues. (Fun fact: there are ~3k debootstrap installations on testing/unstable, compared to 6.2k on stable and 2k on oldstable according to popcon.) Anyway, buildds are not using merged-/usr, so there is no problem with them. > and the sky started falling immediately after that. Hmm, two packages or so were reported to be broken. That is a quite high standard for "sky falling". What would you call an upload that breaks more packages? The monthly apocalypse which we deal with just fine? >> You could have easily asked the tech-ctte back then (or even before) >> instead of waiting until shortly before the Buster freeze and after >> people invested more work. > > It was only shortly before the Buster freeze that we saw this change in > action! Had the switch get flipped sooner we'd have a chance to see the > results. By now, it's much too late to fix things before the freeze > (and I don't see how they could be fixed even had we two years of > time). You keep saying that it is too late to fix anything or that it is too much work, but why do you think so? I've looked at patching packages and how many packages need changes and it does not seem much work; indeed after a week about half of the packages already have a (usually trivial) patch. If you think it is too much work or too many things break, please at least give an estimate of what you are talking about... I feel like only one side is doing any research here. > By now, all we can do is damage control. Which can be a hasty force-merge > or a hasty revert. Unless you can somehow make dpkg-dev omniscient. If we keep merged-/usr as default then we can /recommend/ people to install usrmerge to switch to merged-/usr; reducing the difference between newly-installed and existing setups is a good idea IMHO. I think I filed a report for this two years ago. Maybe we should also mention somewhere that it might be useful to not switch build environments (yet). Ansgar
Bug#914897: debating the wrong thing
On Tue, Dec 04, 2018 at 07:21:11PM +0100, Adam Borowski wrote: > Your figure of ~80 packages counts only packages which went through a > reproducible-builds rebuild. We later learned only a part of the archive > got rebuilt since the bad debootstrap backport. wrong, sigh. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#914897: debating the wrong thing
On Tue, Dec 04, 2018 at 06:48:45PM +0100, Ansgar Burchardt wrote:
> Ian Jackson writes:
> > Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> >> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
> >> systems would no longer be supported. In this case someone would have
> >> to write a unusrmerge program to convert systems with merged-/usr to
> >> systems with unmerged-/usr.
> >
> > Currently merged-usr is broken because it can build packages which do
> > not work on non-merged-usr systems.
>
> In very rare cases (an estimated 0.3% of the archive or so). I'm fairly
> confident that for more than 0.3% of the archive something can go wrong
> when building in non-clean environments.
Your figure of ~80 packages counts only packages which went through a
reproducible-builds rebuild. We later learned only a part of the archive
got rebuilt since the bad debootstrap backport.
> What is technically and socially wrong is reverting a change after a
> small issue was found which is already in the process of getting fixed
> for most packages.
Making packages with non-Debian origin randomly break is not a "small
issue". Remember, we can fix only packages we make ourselves -- not any of
private/PPA/company-wide packages so many of our users make.
> > When we have stopped generating more lossage, we can start to think
> > about whether we want to transition to usrmerge as default, whether to
> > make it mandatory, and if so how the transition should be handled, and
> > on what timescale.
>
> We had the discussion (usrmerge as default) already quite some time
> ago. Why start again at zero? As a random reference, the D-I Stretch
> RC 1 release announcement explicitly stated:
>
> +---
> | * The switch to merged-/usr as the default setting for debootstrap
> |was reverted since it uncovered a number of important issues which
> |might not be all fixed in time for stretch. This setting is
> |expected to come back as the default at the beginning of the next
> |release cycle.
> +---
>
> And just that happened (except a bit later).
Except that the change went live only on 2018-11-10, then waited until
buildds recreated their chroots, then until dinstall and mirror push...
and the sky started falling immediately after that.
We train DDs to not upload packages built in an unclean environment -- I
made ~1000 uploads (mostly sponsored) which did not include a _single_
unclean build. I expect most DDs to be alike, and most of us also do
source-only except to NEW.
We tend to build outside a chroot only during development. Of course we do
test those packages but almost always on the same machine we're sitting at.
Which happens to match the usrmerge status of the package being tested...
> You could have easily asked the tech-ctte back then (or even before)
> instead of waiting until shortly before the Buster freeze and after
> people invested more work.
It was only shortly before the Buster freeze that we saw this change in
action! Had the switch get flipped sooner we'd have a chance to see the
results. By now, it's much too late to fix things before the freeze
(and I don't see how they could be fixed even had we two years of time).
> There is no such crisis. There was also enough time to discuss this in
> the last years or even since June (when it was enabled by default
> again)...
Nope, it got enabled very recently. This is a case where religiously
building stuff in a clean environment bit us -- because _that_ environment
wasn't changed.
By now, all we can do is damage control. Which can be a hasty force-merge
or a hasty revert. Unless you can somehow make dpkg-dev omniscient.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.
Bug#914897: debating the wrong thing
Ian Jackson writes:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
>> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
>> systems would no longer be supported. In this case someone would have
>> to write a unusrmerge program to convert systems with merged-/usr to
>> systems with unmerged-/usr.
>
> Currently merged-usr is broken because it can build packages which do
> not work on non-merged-usr systems.
In very rare cases (an estimated 0.3% of the archive or so). I'm fairly
confident that for more than 0.3% of the archive something can go wrong
when building in non-clean environments.
> It would be quite wrong (both technically and socially) to react to
> this lack of foresight,
The reported problems are not really unexpected...
> lack of consultation,
It was discussed on -devel@ several times. I think LWN also reported
about merged-/usr developments in Debian more than once, it wasn't a
secret cabal development.
So where is the lack of consultation?
> and lack of testing, by pressing forward.
It has been tested for quite a while.
A helpful new test was recently added by the Reproducible Builds project
which allowed to identify most problematic packages.
What is technically and socially wrong is reverting a change after a
small issue was found which is already in the process of getting fixed
for most packages.
> When we have stopped generating more lossage, we can start to think
> about whether we want to transition to usrmerge as default, whether to
> make it mandatory, and if so how the transition should be handled, and
> on what timescale.
We had the discussion (usrmerge as default) already quite some time
ago. Why start again at zero? As a random reference, the D-I Stretch
RC 1 release announcement explicitly stated:
+---
| * The switch to merged-/usr as the default setting for debootstrap
|was reverted since it uncovered a number of important issues which
|might not be all fixed in time for stretch. This setting is
|expected to come back as the default at the beginning of the next
|release cycle.
+---
And just that happened (except a bit later).
You could have easily asked the tech-ctte back then (or even before)
instead of waiting until shortly before the Buster freeze and after
people invested more work.
Making it mandatory or not is an unrelated decision. That can easily
just come later.
> We need the space to discuss those options properly without being
> distracted by what is IMO currently a crisis in stretch-backports and
> buster.
There is no such crisis. There was also enough time to discuss this in
the last years or even since June (when it was enabled by default
again)...
Ansgar
Bug#914897: debating the wrong thing
Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
> systems would no longer be supported. In this case someone would have
> to write a unusrmerge program to convert systems with merged-/usr to
> systems with unmerged-/usr.
Currently merged-usr is broken because it can build packages which do
not work on non-merged-usr systems. It would be quite wrong (both
technically and socially) to react to this lack of foresight, lack of
consultation, and lack of testing, by pressing forward.
What I am suggesting in this bug report is that we revert to the
status quo before the default was changed to usrmerge, that is:
[Adam:]
>> 2. supporting both merged-usr and unmerged-usr
But actually of course "supporting" it in the way that it is currently
"supported" (according to usrmerge proponents) in stretch, sid, and
buster: if you enable it you may build packages which are not
generally useable (and perhaps you may experience other bugs).
This question is urgent for buster because the longer the current
situation continues the more systems there are that build broken
packages.
It is also urgent for stretch-backports. The backports maintainers
have said that they want to keep stretch-backports in line with
buster. Regardless of the wisdom of that policy, the current
situation in stretch-backports seems very bad to me.
The easiest way to fix stretch-backports (without also generating a
need to persuade the backports maintainers to waive their usual
policies) is to revert buster.
When we have stopped generating more lossage, we can start to think
about whether we want to transition to usrmerge as default, whether to
make it mandatory, and if so how the transition should be handled, and
on what timescale.
We have at least two sketches of transitions plans. That longer-term
conversation is a much more complicated one with many more options and
many more factors.
We need the space to discuss those options properly without being
distracted by what is IMO currently a crisis in stretch-backports and
buster.
Ian.
Bug#914897: debating the wrong thing
"Alexander E. Patrakov" writes: > Ansgar Burchardt wrote: >> Making the feature default was discussed years ago which you are surely >> aware of. It's not mandatory. > > Unfortunately I have to disagree here. Merged /usr is already, > de-facto, mandatory for everyone who installs Debian Testing using the > official netinst CD. Yes, but the "make merged-/usr mandatory" refers only to require to merge /usr on upgrades; nobody has asked for there to be an installer option (and I don't think it would be useful). Ansgar
Bug#914897: debating the wrong thing
Ansgar Burchardt wrote: Making the feature default was discussed years ago which you are surely aware of. It's not mandatory. Unfortunately I have to disagree here. Merged /usr is already, de-facto, mandatory for everyone who installs Debian Testing using the official netinst CD. The user is not even asked the question, there is nothing on the help screens. There is simply no opt-out except pressing Alt-F2 and replacing the "debootstrap" script with a wrapper that adds --no-merged-usr to the arguments. In other words, non-merged /usr is currently achievable only by upgrading an old system, or running debootstrap directly, or running old debootstrap, or using major hacks during the install procedure. -- Alexander E. Patrakov
Bug#914897: debating the wrong thing
On Dec 03, Adam Borowski wrote: > unusrmerge would still be still far less work than continuing with 2. Yet I No "unmerge" program is possible since some symlinks are created by maintainer scripts and hence cannot be recreated except by running again the maintainer scripts in the right conditions (which I do not believe would be possible). -- ciao, Marco signature.asc Description: PGP signature
Bug#914897: debating the wrong thing
Adam Borowski writes: > On Mon, Dec 03, 2018 at 10:25:46PM +0100, Ansgar Burchardt wrote: > I believe the difference between those is less than between suboptions of 1 > and 3, but then, as an opponent of 2 as a whole I'm biased. > >> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr >> systems would no longer be supported. > > They'd be exactly as supported as they are today. Ie -- they'll continue to > work, Yes. > and continue to be useless for building packages without a clean > chroot. Oh? What makes you think so? You are free to correct my earlier estimate about the number of problems. So long I'll assume I'm not totally wrong. If I'm wrong by a factor of 3, then 99% of the packages will just build fine. And fixing any problem is in most cases straightforward. >> In this case someone would have to write a unusrmerge program to convert >> systems with merged-/usr to systems with unmerged-/usr. >> Such a program doesn't exist yet and is probably more complicated than >> usrmerge: for example how would it know that a /sbin/iptables -> >> /usr/sbin/iptables symlink would have to be created when unmerging the >> system? Moving files from /usr to / is also more likely to run out of >> disk space (if separate partitions are used for /usr and /). >> >> I'm not sure how long it would take to get this right and so agree that >> (2) or (3b) or (3a-with-support-in-buster) are reasonable choices. > > unusrmerge would still be still far less work than continuing with 2. Why do you think so? Trivial patches for the remaining few packages seem easier. > Yet I don't understand your claim why 1 or 3a w/o usrmerge-in-buster > would cause any problems. In fact, they require no work at all (in > Buster's cycle) beyond an upload of debootstrap. Unless someone builds a package in an already existing install... If not being able to build packages in existing installations is not a problem, I'm even less sure what the problem with merged-/usr by default is supposed to be? Ansgar
Bug#914897: debating the wrong thing
On Mon, Dec 03, 2018 at 10:25:46PM +0100, Ansgar Burchardt wrote: > Gunnar Wolf writes: > > Adam Borowski dijo [Mon, Dec 03, 2018 at 12:36:29AM +0100]: > >> (...) > >> So, let's enumerate possible outcomes: > >> > >> 1. no usrmerge > >> 1a. no moves at all (no effort needed!) > >> 1b. moves via some dh_usrmove tool, until /bin is empty > >> 2. supporting both merged-usr and unmerged-usr > >> 3. mandatory usrmerge > >> 3a. by Bullseye > >> 3b. by Buster > >> > >> Unless the TC decides for 2., all this work will be a pure waste of yours > >> and maintainers' time. > > > > ...One thing I fear here, that's also not being clearly debated AFAICT > > (although the "urgency" of this report points in the right direction) > > is that if the TC decides towards anything but 2 or 3b, we will have a > > hard time reaching and following through the freeze targets proposed > > by the Release Team. Which is something we don't want. > > I don't think this list is good as (2) doesn't say anything about the > question asked originally (the default) and (3a) doesn't say anything > about what happens for Buster. > > Currently implemented is (2) + default to merged-/usr for new > installations. Good point -- so there's: 2. supporting both merged-usr and unmerged-usr 2a. default to merged 2b. default to unmerged I believe the difference between those is less than between suboptions of 1 and 3, but then, as an opponent of 2 as a whole I'm biased. > Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr > systems would no longer be supported. They'd be exactly as supported as they are today. Ie -- they'll continue to work, and continue to be useless for building packages without a clean chroot. > In this case someone would have to write a unusrmerge program to convert > systems with merged-/usr to systems with unmerged-/usr. > Such a program doesn't exist yet and is probably more complicated than > usrmerge: for example how would it know that a /sbin/iptables -> > /usr/sbin/iptables symlink would have to be created when unmerging the > system? Moving files from /usr to / is also more likely to run out of > disk space (if separate partitions are used for /usr and /). > > I'm not sure how long it would take to get this right and so agree that > (2) or (3b) or (3a-with-support-in-buster) are reasonable choices. unusrmerge would still be still far less work than continuing with 2. Yet I don't understand your claim why 1 or 3a w/o usrmerge-in-buster would cause any problems. In fact, they require no work at all (in Buster's cycle) beyond an upload of debootstrap. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
Bug#914897: debating the wrong thing
Gunnar Wolf writes: > Adam Borowski dijo [Mon, Dec 03, 2018 at 12:36:29AM +0100]: >> (...) >> So, let's enumerate possible outcomes: >> >> 1. no usrmerge >> 1a. no moves at all (no effort needed!) >> 1b. moves via some dh_usrmove tool, until /bin is empty >> 2. supporting both merged-usr and unmerged-usr >> 3. mandatory usrmerge >> 3a. by Bullseye >> 3b. by Buster >> >> Unless the TC decides for 2., all this work will be a pure waste of yours >> and maintainers' time. > > ...One thing I fear here, that's also not being clearly debated AFAICT > (although the "urgency" of this report points in the right direction) > is that if the TC decides towards anything but 2 or 3b, we will have a > hard time reaching and following through the freeze targets proposed > by the Release Team. Which is something we don't want. I don't think this list is good as (2) doesn't say anything about the question asked originally (the default) and (3a) doesn't say anything about what happens for Buster. Currently implemented is (2) + default to merged-/usr for new installations. Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr systems would no longer be supported. In this case someone would have to write a unusrmerge program to convert systems with merged-/usr to systems with unmerged-/usr. Such a program doesn't exist yet and is probably more complicated than usrmerge: for example how would it know that a /sbin/iptables -> /usr/sbin/iptables symlink would have to be created when unmerging the system? Moving files from /usr to / is also more likely to run out of disk space (if separate partitions are used for /usr and /). I'm not sure how long it would take to get this right and so agree that (2) or (3b) or (3a-with-support-in-buster) are reasonable choices. >> With 1a, 1b, 3a the result will be "revert the change in debootstrap" (in >> 3a "for now"). With 3b you need some way to make sure existing systems are >> converted (also with 3a except for far more time for testing). > > I agree with your assessment. There are still too many mails I haven't > read, though, and I cannot commit my hypothetical vote so far, but I > think the sanest way will be to revert the change in debootstrap. So (2) with the default to non-merged-/usr or (3a)? I'm not sure why (2) should not default to merged-/usr though. Ansgar
Bug#914897: debating the wrong thing
Adam Borowski dijo [Mon, Dec 03, 2018 at 12:36:29AM +0100]: > (...) > So, let's enumerate possible outcomes: > > 1. no usrmerge > 1a. no moves at all (no effort needed!) > 1b. moves via some dh_usrmove tool, until /bin is empty > 2. supporting both merged-usr and unmerged-usr > 3. mandatory usrmerge > 3a. by Bullseye > 3b. by Buster > > Unless the TC decides for 2., all this work will be a pure waste of yours > and maintainers' time. ...One thing I fear here, that's also not being clearly debated AFAICT (although the "urgency" of this report points in the right direction) is that if the TC decides towards anything but 2 or 3b, we will have a hard time reaching and following through the freeze targets proposed by the Release Team. Which is something we don't want. > With 1a, 1b, 3a the result will be "revert the change in debootstrap" (in > 3a "for now"). With 3b you need some way to make sure existing systems are > converted (also with 3a except for far more time for testing). I agree with your assessment. There are still too many mails I haven't read, though, and I cannot commit my hypothetical vote so far, but I think the sanest way will be to revert the change in debootstrap.
Bug#914897: debating the wrong thing
On Mon, 2018-12-03 at 12:38 +, Ian Jackson wrote:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> > It is very demotivating to have discussed and implemented something
> > mostly years ago, for people then to come and complain "let's not
> > do
> > this at all" years later.
>
> We were told it would be optional. Unfortunately it turns out that
> the design is broken and it cannot sensibly be made optional.
There is no indication of that. So I'll assume the design isn't
broken.
You aren't entitled to just claim that.
> Nor does a failure to review and object to your design of an optional
> feature mean that you are entitled to assume consent for making the
> feature default or mandatory.
Making the feature default was discussed years ago which you are surely
aware of. It's not mandatory.
> The problem comes when a niche optional feature, with wide-ranging
> implications, is suddenly promoted to the default, without proper
> consultation and without a proper transition plan.
It wasn't made "suddenly" the default.
Ansgar
Bug#914897: debating the wrong thing
Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> It is very demotivating to have discussed and implemented something
> mostly years ago, for people then to come and complain "let's not do
> this at all" years later.
We were told it would be optional. Unfortunately it turns out that
the design is broken and it cannot sensibly be made optional.
It is not the responsibility of the wider community to review your
design for an optional feature.
Nor does a failure to review and object to your design of an optional
feature mean that you are entitled to assume consent for making the
feature default or mandatory.
Debian is full of optional features. I'm sure many of them are broken
in one way or another. Obviously one can't spend one's life going
round trying to abolish everything one thinks is somehow broken, or
foolish. That would be really nasty.
The problem comes when a niche optional feature, with wide-ranging
implications, is suddenly promoted to the default, without proper
consultation and without a proper transition plan.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#914897: debating the wrong thing
Adam Borowski writes: > I see that we're debating the merits of merged-usr vs non-merged-usr, while > expending lots of effort and filing bugs (requiring further urgent action of > unrelated maintainers), for little gain. There is no "urgent action" required (unlike, say, for the last glibc update). If you don't want support for merged-/usr, could you please discuss this back in 2016 or before that? Also I feel a general discussion would probably just be too long-winded and touch too many unrelated issues; there is not even a terse list of claimed problems. It is very demotivating to have discussed and implemented something mostly years ago, for people then to come and complain "let's not do this at all" years later. Maybe we should also revisit Multi-Arch now that we know that `Multi-Arch: foreign` relations as implemented can result in non-booting systems... Or really revisit the init system question before people file bugs that require further urgent action for little gain (it's probably too late in the release cycle to push in elogind anyway). There is also the question if it is still worth to spend maintainer efforts to ship sysvinit scripts if this means we lose the advantages of declarative service files (which means far more work than merged-/usr changes)... We could also open a tech-ctte bug for secure boot before I spend any more time on it (there are still a few things). Luckily having this discussion delays me spending time on the remaining things I wanted to look at, so at least not more time is wasted. (Not that I currently have too much time for Debian anyway, and secure boot is quite a lot of work for something I don't need...) Ansgar
Bug#914897: debating the wrong thing
I see that we're debating the merits of merged-usr vs non-merged-usr, while expending lots of effort and filing bugs (requiring further urgent action of unrelated maintainers), for little gain. In the above, note that the debate vs effort touch different problems: 1. is usrmerge good? vs 2. how to support both? I say that 1. is a relatively small issue. After dropping support for booting from split /-vs-/usr without initrd, the difference doesn't really matter. I'm against pointless moves, but it's not worth an endless debate. My objection is: repainting the house is a lot of work, paint fumes are bad for health, the old color was fine and the old paint isn't noticeably flaky. On the other hand, 2. is madness. It's taking down load-bearing walls just so you can have visible sides of both colours. All the bugs you folks just filed are completely moot if we go all-in, all-out or step-back-then-in. So please at least stop filing extra bugs before the TC decides on the course. So, let's enumerate possible outcomes: 1. no usrmerge 1a. no moves at all (no effort needed!) 1b. moves via some dh_usrmove tool, until /bin is empty 2. supporting both merged-usr and unmerged-usr 3. mandatory usrmerge 3a. by Bullseye 3b. by Buster Unless the TC decides for 2., all this work will be a pure waste of yours and maintainers' time. With 1a, 1b, 3a the result will be "revert the change in debootstrap" (in 3a "for now"). With 3b you need some way to make sure existing systems are converted (also with 3a except for far more time for testing). And any effort spent doing one of the numbered choices is wasted if we end up with a choice with a different number. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a wordly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
