Bug#727708: systemd jessie -> jessie+1 upgrade problems

[Adrian Bunk <bunk@stusta.de>]

On Wed, Dec 18, 2013 at 03:10:19PM +0200, Uoti Urpala wrote:
> On Wed, 2013-12-18 at 13:34 +0200, Adrian Bunk wrote:
>...
> > When not using systemd as pid 1, that risk would be confined to the 
> > parts of systemd Debian would be using (currently only udev).
> 
> I think you still misread the argument: IMO it's clear that it
> considered more than udev as likely to be required, even if udev is the
> only one in current Debian. So if you disagree, you should at least
> address the question of why you believe udev will stay the only one.

I think you misread what I wrote.

I wrote "part*s* of systemd", and that *currently* udev is the only one.


> > > At some level, we also need to be community players.  Since upgrade
> > > stability is important to us, we should advocate for it in open-source
> > > projects that we depend on.  On the flip side, if enough of the rest of
> > > the community after having carefully considered our arguments decides
> > > that our desire for stability is too expensive, perhaps we need to
> > > reconsider our position.  I hope we don't need to do that, but sometimes
> > > when enough of the rest of the world disagrees with you, you need to
> > > move on.
> 
> 
> > systemd upstream only reluctantly supports the option to have a separate
> > /usr (as currently mandated by Debian policy), and I would not be 
> > surprised if that gets dropped any time if it becomes an obstacle
> > for development of any part of systemd.
> 
> You're mixing two separate issues (or at least not clearly indicating
> which one you're talking about). Systemd fully supports having a
> separate /usr partition, and that is in no way deprecated AFAIK. What
> has changed compared to "old practice" is that /usr needs to be mounted
> together with root

Thanks for the clarification, I missed that this useful part of having a 
separate /usr (mounting it later) is already broken with systemd.


> Whether
> the old way of later /usr mounting could keep working with any other
> init either is questionable.

I am not seeing any reason why it should suddenly stop working with 
sysvinit.


> A development model where you have to wait 3+ years before you can have
> hard dependencies on the new features you write now is obviously very
> problematic. IMO such restraints should never be taken for granted;
> upgrade schemes should always be planned to at least make it possible to
> have newer dependencies without too much trouble.

For normal dependencies there is no such restraint.

Only when the dependency is on a new kernel there is a problem and the 
upgrade becomes complicated.


cu
Adrian

BTW: Please Cc me on replies - even though I am subscribed to the bug,
     I don't seem to get the mails.

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed