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
Re: Bug#915392: devel/tech-ctte is outdated on the list of decided matters
On Mon, 2018-12-03 at 10:18 -0500, Boyuan Yang wrote: > FYI, I skimmed through debian-devel-announce between 2015 and 2018 and found 3 > new decisions. Changes already committed here: > > https://salsa.debian.org/webmaster-team/webwml/commit/14e3f9fee45f3aae7d3e5af0cc3a376b69fc6fd8 I wonder if it would be a good idea to have the CTTE chair be responsible for committing the decisions of the CTTE to the website? This way we won't get into the situation where the info is outdated. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
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: debootstrap, buster: Please disabled merged /usr by default
On Sun, 2018-12-02 at 21:04 +0100, Marc Haber wrote: > > The next debhelper change might choose to give / instead of /usr as a > target directory by default, moving hundreds of megabytes from /usr to / > over time. This solution was proposed by GNU/Hurd several years ago, and was scrapped due to not being big enough player in the *NIX world: https://www.gnu.org/software/hurd/faq/slash_usr_symlink.html The distinction between / and /usr has historical reasons. Back when Unix systems were booted from two tapes, a small root tape and a big user tape. Today, we like to use different partitions for these two spaces. The Hurd throws this historical garbage away. We think that we have found a more flexible solution called union filesystems, which allow to create virtual filesystems which are the union of several other filesystems. However, support for union filesystems is still in early development. About unionfs: Unionfs allows you to simply union one directory or translator into another one, so you see the files of both of them side by side. More here: https://www.gnu.org/software/hurd/hurd/translator/unionfs.html
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.
