2015-02-17 13:57 GMT+01:00 Alastair McKinstry <alastair.mckins...@sceal.ie>:
> [...]
>
> Examination after the fact showed that if I'd had the correct packages
> installed, it would have worked.
> So from a Debian perspective this was 'notabug'.
> (modules that were not needed day-to-day had been deleted by hand to
> make space on /.
> A broken initrd was then built during dist-upgrade. My fault).
>
> But this didn't change the user experience: a system broke badly during
> systemd upgrade due to local changes. A blaming exercise of "your own
> fault for doing X" and "you should have known Y" doesn't change the
> fact that systemd changes are so comprehensive and all-invasive that
> systemd works well for two groups:
With that argumentation, we could not make any changes to Debian
anymore, because users could do any arbitrary change which could break
upgrade, e.g. removing stuff from /sbin manually etc.
If you perform invasive changes on your system, and then do a Debian
upgrade, you should be able to handle the upgrade and take additional
care to make the upgrade work properly with your local changes.
> either 'simple users' who make no changes to the standard
> configurations, or full systemd developers who know the detailed changes
> that it makes in all areas and the consequences for their computers.
>
> Users who make a few local changes to their system, not simple
> configuration changes but code / scripting
> changes of their own, now live in trepidation to what systemd will do.
That's not systemd-specific. If you make bigger invasive changes, I
would expect you to *know* what you are doing and be able to handle
the consequences of the changes. There is no way we can account for
random changes in Debian packaging.
> Its no longer enough to run a "standard Debian + a unique firewall whose
> design I made and know well"
> now live in trepidation, not sure what systemd changes will come next.
Everything is changing constantly :-) And systemd does have migration
paths in case stuff is changed. But again, this particular "I don't
know what change will be next" issue is not specific to systemd -
Debian itself might introduce new default packages at any time, or
perform large transitions like the multiarch-transition, which break
your assumptions on how stuff usually was (in that example, libraries
suddently being installed into /usr/lib/<triplet>).
> Most components in Linux are small, self-contained, concisely
> documented. Not so for systemd.
That's a false assumption. Systemd consists of small, well-documented
tools which happen to be shipped in one tarball and are designed to
work together and work together well.
Just take a look at the contants of the "systemd" Debian package ;-)
Cheers,
Matthias
--
I welcome VSRE emails. See http://vsre.info/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAKNHny8PoSv00nbqHbX0jNpob2tOUOTb80AYrYr=lyuusfp...@mail.gmail.com
