On 01/04/2016 11:41 AM, Marc Haber wrote:
> On Sun, 03 Jan 2016 13:28:14 -0800, Russ Allbery <rra@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
Attachment:
signature.asc
Description: OpenPGP digital signature