On Mon, 4 Jan 2016 13:38:15 +0100, Christian Seiler
<christ...@iwakd.de> wrote:
>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?
Since when does one have to actually work on something to be allowed
to find it important and interesting. You would have a point if you
told me to put better maintenance on the packages that I have taken
responsibility for instead of telling me to commit to do _more_ work
than I am already not properly doing.
>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.
Yes, that's really a pity.
>> 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.)
My beef with Ubuntu is their release cycle and the fact that Debian is
being slowly modified to suit their cycle. Leaving behind Debian's
core values in the process.
>Btw. Is Debian there to mindlessly follow RedHat or Ubuntu?
In my opinion, no. Debian used to be there for technical leadership
and stability, living up to the name of the Universal Operating
System. Even if that meant not releasing once a year. Alas, times are
changing.
>> 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.
If hundreds of megabytes of software would get moved from /usr to /,
this would certainly overflow my root file systems. In fact, as I have
understood things, software will move from / to /usr, making the
system completely unuseable if the multi-gigabytes /usr does not mount
for some reason.
The upside of this is that this will free up space in / which will be
needed for a dedicated recovery image. Too bad that we don't have such
a thing ourselves and have to recommend third-party products like grml
while at the same time making development of those third-party
products considerably harder by our release decisions.
>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.
My standard Debian server image is about this size in total.
>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.
Yes, this happens. Do we really have to _force_ this? It is annoying
enough when it happens caused by the normal flow of things. Even if
this is the case, not all systems will explode during the same system
upgrades, allowing the local admin to spread those changes over two or
even three releases. If we would, in some future, ship an upgrade that
uncaringly would _require_ a repartitioning, this spread would not be
possible, and it would undoubtedly call up management attention, which
could in turn lead to management taking vendor decisions that we don't
want.
>If you also separate out
>/var the numbers game changes a bit, but the principle remains.
/var is of couse separated out on all but the smallest boxes.
>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.
_This_ will become more a problem when we force things onto /usr.
>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.
You forgot that the UsrMerge will want a grml or something on /boot as
well. Yes, that's an additional nuisance. Thankfully the recovery
system does not need to be inside the actual image in virtualized
environments.
>It's always been a fact that upgrades might require repartitioning,
That does not mean that we're entitled to force this.
>> 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.
That does not mean that we're entitled to needlessly add a big detail
that changes.
> - 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
If I forget to unconfigure the /usr backup, I get errors. And I need
to change documentation, which will probably trigger a review process
with management attention.
> 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
If I use a backup scheme with a --one-file-system switch, and I forget
to adapt this, I end up with errorless, but incomplete backups. If I
change things, I need to change documentation, see above.
> 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?
Not everywhere. This might look unprofessional, but I am usually
running the small little gallic Linux village inside "all Windows"
shops, and when I ask organizations for test environments, I might end
up with "nah, too much hassle, we'll just use Windows instead for your
job".
Organizations that run a bigger Linux show than that usually do so
with Enterprise Linuxes, so Debian is already gone there.
>I don't see UsrMerge as particularly impactful if I compare it to
>other changes in the past.
I disagree, but it's only a gut feeling. With the jessie systemd
migration, that gut feeling was wrong, but it was right about exim
generating its own DH parameters which would have been a good idea to
keep.
>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.
You have a big point here. All I want is documentation and commitments
so that no surprises come.
Greetings
Marc
P.S.: Thanks for your calm and patient reasoning that is so completely
devoid of opinion and polemics (no irony here). I am noticing that
replying to your messages does a really good job to calm me down.
Which is unfortunately not the case for other participants of this
discussion.
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
