On 01/04/2016 11:41 AM, Marc Haber wrote: > On Sun, 03 Jan 2016 13:28:14 -0800, Russ Allbery <r...@debian.org> > wrote: >> I do understand why people working in the embedded space care about some >> unusual mount orderings, file system separations, and very light cores, >> and I hope that we can accomodate and support all of their use cases >> inside Debian. I think that's the most productive part of this thread. > > We have already shown how "much" we care about the users of non-Linux > kernels in Debian ("not at all, they can happily go fishing").
So why aren't you on the list of porters for either Hurd of kFreeBSD? https://release.debian.org/stretch/arch_qualify.html (Hover over the number of porters to get a list of names.) The main concern for kFreeBSD w.r.t. Jessie was manpower. The kFreeBSD porters have a right to complain about a lack of interest, but you certainly don't. You could also say the same (not caring about them) of HA users: Jessie has no Pacemaker, because nobody cared about that during the Jessie release cycle. It was completely broken at that point and thus removed from the release. The current recommendation for HA users is to stick with Wheezy for now. When more people realized that, people complained that that sucked - but instead of just complaining and complaining and complaining constantly, there are now (new) people working on the HA stack for Debian, because they saw that there should be work put into it - and I'm quite confident that Stretch will have a very well supported HA stack again. (Shout out and thanks to the people working on that btw!) > I have no doubt that we're going to do the same thing to embedded > users if we can trade those users for a few seconds per year in > startup time. Please don't warm up the tired old systemd discussions with cheap polemics. It doesn't help your cause. > And we're all doing this to keep our upstreams and Ubuntu happy. Have you read *any* of the technical arguments in this thread? (Btw. Ubuntu does NOT have UsrMerge. Ubuntu switched to systemd AFTER Debian decided to use systemd as default.) Btw. Is Debian there to mindlessly follow RedHat or Ubuntu? It would be _very_ helpful if people could make up their mind on this, it's very confusing to me... > I, for example, am afraid of having to merge /usr in existing systems > during upgrades, causing repartitions to be necessary. I am afraid of > partition layout suddenly not fitting any more during an upgrade, > causing downtimes and customers considering to take the opportunity to > migrate to a really supported enterprise distribution. Sorry, but this is bogus, because this is a problem you have on every every upgrade. In the past I've already had to repartition systems because / had become too small, because the amount of software required to be there had grown (to support more storage solutions for mounting /usr) and also the kernel modules had grown. Statistics: deboostrap of lenny (via archive.d.o) + kernel: 313 MiB in total, 99 MiB on /usr => 214 MiB on / debootstrap of jessie + kernel: 618 MiB in total, 203 MiB on /usr => 415 MiB on / And that's just ONE kernel, if you upgrade you usually have additional kernels lying around. Plus I didn't install a lot of other utilities that are present on many systems, this is really minimal. So let's say you installed lenny and had 512 MiB for / (with separate /usr) because you thought back then that it was more than enough (more than double the installed size) - and upgrade to Jessie will either run out of disk space or come very close to it. If you also separate out /var the numbers game changes a bit, but the principle remains. Also, the amount of space software requires on /usr is larger on Jessie - so even if your / partition is large enough, /usr might already be too small un upgrades. I've also had the case multiple times where the space I allocated for /boot wasn't enough: I remember that 15 years ago I used to allocate 32 MiB or so for /boot, and that was *plenty* enough for it (kernel image around 1-2 MiB, initrd the same, so typically 10 MiB or so used with ~ 2 kernels insetalled) - but that is simply not true anymore and /boot (if you separate it) should now be probably sized to ~ 256 MiB to accomodate current kernels and initrds... (Unless you compile your kernel by yourself and tailor it to your hardware, then you can get away with far less.) OTOH, 256 MiB for /boot is nothing if you look at current storage sizes, so it's not like the current requirements are inherently unreasonable. I can also remember a time nearly twenty years ago when I copied the entire source code of KDE onto three (maybe four) 1.44 MiB floppy drives with tar. Good luck doing that with even minimalistic DEs nowadays. ;-) (Good luck finding a floppy drive nowadays. ;-)) It's always been a fact that upgrades might require repartitioning, and this has nothing to do with UsrMerge. UsrMerge might cause some people to already repartition one Debian release earlier, sure, but at some point they will have to anyway. > And, I really don't want to have to adapt, test and verify scripts and > backup schemes to changed partition layout. This will be necessary for > new systems, and it is really a horror vision to have to do this for > existing systems during upgrades. You will always have to adapt things to upgrades, because lots of small details can change. Also I don't see how putting things in /usr will have a large impact on this: - backups: either you image entire partitions, then the sizes of the images relative to each other changes even better: with merged /usr, you only need to backup / (because it contains /etc) and don't need to backup /usr because than can be recreated trivially from just reinstalling the packages - so you might even save an image or you backup on file basis - and if you do backup /bin, /usr etc. now you just need to backup /usr - I don't see any amount of complexity added by UsrMerge Sure, you need to test if something breaks (because it always can, regardless of whether UsrMerge is done or not), but _surely_ you have a test environment before performing a dist-upgrade of your entire production system? Right? - scripts: since all binaries will still be reachable from their previous locations, nothing should break unless you do some really weird things (such as checking that a certain binary is NOT present in /usr/bin) I don't see UsrMerge as particularly impactful if I compare it to other changes in the past. It's not that nobody will be affected by it, but there are other changes that have been made that have had far bigger ramifications. >> Another word for "giving up" is "applying sane prioritization." We can't >> fix every wishlist bug. Is this one actually worth the effort? > > So it is a wishlist bug to keep things as broken as they were always > been? No, because things will break more and more. See my example bug, #777547: that did work up to Wheezy, in broke it Jessie, but nobody cared enough to fix it so far. (It still affects Stretch/Sid.) So we can either keep everything as is, with no plan for the future, and things will simply continue to deteriorate - or we embrace the fact that what has been done in the past doesn't work anymore, and see how we can improve the situation from there. Regards, Christian
signature.asc
Description: OpenPGP digital signature