Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Ian Jackson]

Svante Signell writes ("Re: upgrades must not change the installed init system 
[was: Re: Cinnamon environment now available in testing]"):
> As you can see from that bug report the systemd maintainers overrides
> every attempt to change severity of that bug to wishlist and wontfix.
> 
> Is it possible to reassign this bug to the CTTE, as the systemd-shim |
> systemd-sysv debate was in #762194 as a follow-up of the libpam-systemd
> bug #746578. Do you have to be a member of the CTTE to do this?

No, you definitely don't have to be a member of the TC (or even a DD
or DM or maintainer) to refer a matter to the TC.

But as a matter of bug organisation, it's often better to file a new
ug against tech-ctte, than to reassign an existing bug - eg if the
existing bug has a very long discussion containing many side issues.
Filing a new bug gives you the opportunity to write a summary of the
issues you actually want the TC to decide on.  You can then set the
existing long bug to be blocked by the new TC bug.

Ian.


-- 
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/21541.27963.527299.122...@chiark.greenend.org.uk

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Svante Signell]

On Fri, 2014-09-26 at 13:04 +0200, Carlos Alberto Lopez Perez wrote:
> On 11/09/14 14:36, Ben Hutchings wrote:
> > On Wed, 2014-09-10 at 21:36 +, Nick Phillips wrote:
> > [...]
> >> Debian has a good and hard-earned reputation for not messing up
> >> sysadmins' changes; upgrading to systemd - however wonderful it is (and
> >> I confess to having no opinion on that) - without at least a debconf
> >> prompt of a reasonable priority telling them what is about to happen and
> >> offering a bailout, is guaranteed to lose us reputation and users.
> > [...]
> > 
> > I do agree that at least some kind of high-priority notice is needed.
> > 
> > Ben.
> > 
> 
> Unfortunately systemd maintainers don't agree on this. (#747535)

As you can see from that bug report the systemd maintainers overrides
every attempt to change severity of that bug to wishlist and wontfix.

Is it possible to reassign this bug to the CTTE, as the systemd-shim |
systemd-sysv debate was in #762194 as a follow-up of the libpam-systemd
bug #746578. Do you have to be a member of the CTTE to do this?



-- 
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/1411732659.4530.3.ca...@gmail.com

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Carlos Alberto Lopez Perez]

On 11/09/14 14:36, Ben Hutchings wrote:
> On Wed, 2014-09-10 at 21:36 +, Nick Phillips wrote:
> [...]
>> Debian has a good and hard-earned reputation for not messing up
>> sysadmins' changes; upgrading to systemd - however wonderful it is (and
>> I confess to having no opinion on that) - without at least a debconf
>> prompt of a reasonable priority telling them what is about to happen and
>> offering a bailout, is guaranteed to lose us reputation and users.
> [...]
> 
> I do agree that at least some kind of high-priority notice is needed.
> 
> Ben.
> 

Unfortunately systemd maintainers don't agree on this. (#747535)



signature.asc
Description: OpenPGP digital signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Noel Torres]

On Wednesday, 10 de September de 2014 21:26:50 Matthias Urlichs escribió:
> Hi,
> 
> Steve Langasek:
> > On Wed, Sep 10, 2014 at 08:28:36PM +0100, Marcin Kulisz wrote:
> > > What about cases when init scripts doesn't come from any package but
> > > are crafted by hand?
> > 
> > It's straightforward to check for init scripts that are not owned by any
> > packages.
> 
> … and besides, systemd should just work with them.
> If they descend from /etc/init.d/skeleton, that is.
> 
> Not having the requisite metadata at the top of the script might me a more
> reliable indicator than not belonging to a package.

I would bet that most hand made init scripts do not descend from 
/e/i/skeleton, and they have runlevels and such crafted also by hand on the 
specific system where they are deployed.

Regards

Noel
er Envite


signature.asc
Description: This is a digitally signed message part.

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Noel Torres]

On Thursday, 11 de September de 2014 08:00:57 Marc Haber escribió:
> On Thu, 11 Sep 2014 00:04:07 -0300, Martinx - ?
> 
>  wrote:
> > Also, during Debian 8 installation, please, provide an "altinit" option (
> >
> >http://pyro.eu.org/debian/pool/main/d/debian-altinit/ ?), so, people can
> >choose between systemd / sysvinit (before 1st boot). I know that it seems
> >easy to just "apt-get install sysvinit-core" after install (1st boot) but,
> >at least, Debian users will have an option to select a well tested, init
> >system, while it is fully supported.
> 
> Please note that our init scripts are going to be a lot less reliable
> in a world where only a fraction of our users will actually use them.
> 
> Many maintainers will reduce their priority on the to-do list.
> 
> Greetings
> Marc

Thay _you_ will reduce their priority in your to-do list does not mean that 
many will do.

Regards

Noel
er Envite


signature.asc
Description: This is a digitally signed message part.

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Marc Haber]

On Sat, 13 Sep 2014 05:58:11 +0200, Matthias Urlichs
 wrote:
>Marc Haber:
>> sysvinit init scripts will suffer heavy bitrot in jessie+1.
>> 
>Possibly. But let's get Jessie out the door first …

So that it'll be completely impossible to roll back?

Not that I seriously believe that we got the balls to do that.

Greetings
Marc
-- 
-- !! 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


--
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/e1xsrmj-0006gq...@swivel.zugschlus.de

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[lee]

Carlos Alberto Lopez Perez  writes:

> On 09/09/14 22:34, Carlos Alberto Lopez Perez wrote:
>> I truly believe that making systemd the default without asking the user
>> to test it first, is going to cause more breakage and angry users than
>> doing it the other way.
>
> s/making systemd the default/replacing the user init system with systemd on 
> upgrades/

Yes, and I'd be majorly pissed if I was suddenly forced to use systemd
or if such major changes as replacing the init system were made without
any choice or notice.

Debian has --- or at least used to have --- a policy that users will be
informed about changes to configuration files when updates are
performed, and those include the init scripts.  They are --- or at least
were --- given a choice to decide what to do when an existing
configuration file or init script would be replaced by the version in
the package.

On top of that, remember what Debian did when exim3 was obsoleted by
exim4 and when squid3 became available as an alternative to squid2.7:

Exim is *still* designated explicitly as exim4 many years (over a decade
now?) after version 4 replaced version 3, and for a while, both exim3
and exim4 were available in Debian.  I appreciated this way of doing the
transition.

Squid 2.7 is *still* available in Debian, together with squid3.  I
appreciate that very much since I'm actually using squid2.7 because
squid3 is still missing features I require and which squid2.7 has.

And now Debian wants to:


* give up the policy (or at least tradition) of informing users of
  changes to configuration files/init scripts

* force a major change upon its users by replacing the init system
  without any notice at all and no choice given

* leave its users completely alone with all the breakage that may be
  caused, with no choice and no solution

* quietly go with a default init system that raises significant concerns
  among the users and makes Debian broken by design


I'm finding this outrageous.  The quality of Debian has already declined
over the years, which is a pity.  With suddenly switching to brokenarch
without any regards for the users who need a working system and no fix
whatsoever in sight, Debian has already driven me away after over 15
years because that kind of unreliability is unacceptable.  I'm only back
because I managed to set up my xen-server with Debian but not with
Centos.  And I need it working, not broken.

Now you're considering to make the same mistake again and to destroy the
last bit of good reputation and reliability Debian might have and to
remove such appreciable features as to inform users about changes and to
give them choices.

Let me remind you:


"Our priorities are our users and free software

We will be guided by the needs of our users and the free software
community. We will place their interests first in our priorities. We
will support the needs of our users for operation in many different
kinds of computing environments. [...] we will provide an integrated
system of high-quality materials"[1]


Please either update the social contract, or stick to it.


[1]: https://www.debian.org/social_contract


-- 
Knowledge is volatile and fluid.  Software is power.


-- 
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/87egvfybcx@yun.yagibdah.de

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Matthias Urlichs]

Hi,

Marc Haber:
> sysvinit init scripts will suffer heavy bitrot in jessie+1.
> 
Possibly. But let's get Jessie out the door first …
-- 
-- Matthias Urlichs


-- 
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/20140913035810.ge19...@smurf.noris.de

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Marc Haber]

On Fri, 12 Sep 2014 16:27:58 +0200, Thorsten Glaser
 wrote:
>Nobody says jessie+1 will not permit running sysvinit any more,
>and the CTTE rulings explicitly did not touch that topic which
>implies some amount of scepsis.

sysvinit init scripts will suffer heavy bitrot in jessie+1.

Greetings
Marc
-- 
-- !! 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


--
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/e1xsy7p-0001vt...@swivel.zugschlus.de

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Thorsten Glaser]

On Wed, 10 Sep 2014, Nick Phillips wrote:

> Debian has a good and hard-earned reputation for not messing up
> sysadmins' changes

Agreed. This is about the only thing I can currently use to
argue for use of Debian over *buntu in some places.

> So, is it actually feasible to provide such a prompt?

Not with debconf. Short of patching the apt in stable (and
aptitude, and cupt, and and and…) there is nothing that can
reliably show such a prompt.

The consequence is easy: show a debconf prompt on upgrade
that recomments the admin to “sudo apt-get install systemd-sysv”
and never ever switch a system automatically.

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!


--
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/alpine.deb.2.11.1409121631200.7...@tglase.lan.tarent.de

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Thorsten Glaser]

On Tue, 9 Sep 2014, Ansgar Burchardt wrote:

> We could delay the transition-on-upgrade by one release, but the
> migration from sysvinit to systemd on a Jessie -> Jessie+1 upgrade will
> probably end up less tested (though systemd itself would probably be
> more tested by then).

Nobody says jessie+1 will not permit running sysvinit any more,
and the CTTE rulings explicitly did not touch that topic which
implies some amount of scepsis.

Plus, sysvinit must probably be kept for non-linux arches anyway
(the Hurd people are happy enough to have even that much), so we
can keep it working for the linux arches too.

> Having only some systems switch to a different init system on upgrade
> seems potentially confusing to me.

Agreed, which just persuaded me to believe that even people
running GNOME should not be switched on upgrade, but rather
required to switch first (or after the upgrade), so that no
existing Debian system is auto-switched to systemd.

> That said, it would be nice if
> systemd-sysv could check for common problems on installation and issue a

Agree.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
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/alpine.deb.2.11.1409121625330.7...@tglase.lan.tarent.de

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Thorsten Glaser]

On Tue, 9 Sep 2014, Mathieu Parent wrote:

> 4) Upgrade to systemd silently without asking the user AND add a grub
> entry to use old init

These are the Linux bootloaders I came up within less than
five minutes of searching the ’net:

• Acronis OS Selector
• AiR-Boot
• AKernelLoader
• AMIBOOT
• APEX
• ARAnyM LILO
• ARCBOOT
• Barebox
• Boot Camp
• BootIt Next Generation
• BootKey
• BOOTSTRA.TTP
• BootX
• BURG
• CFE
• coreboot
• EFI
• ELILO
• Emile
• EXTLINUX
• FreeLoader 
• GRUB 1
• GRUB 2
• GRUB4DOS
• Gujin
• Gummiboot
• Kexecboot
• LILO
• LOADLIN.EXE
• MasterBooter
• PALO
• Penguin
• PMON
• PXELINUX
• Qi
• quik
• Redboot
• rEFInd
• rrload
• SILO
• Smart Boot Manager
• SYSLINUX
• TFTPLILO
• U-Boot
• XOSL
• Yaboot
• YAMON

I’ve heard of barely half of them, and have had personal
experience with half of that, but that still makes for a
dozen booloaders I know of.

Many of these require the user to copy out the kernel and
initrd from the Linux-controlled space, for example into
NAND flash or a FAT partition or a HFS partition or the
host filesystem or whatever.

So: No. Not a solution.

https://julien.danjou.info/media/images/blog/2014/unacceptable.jpg

bye,
//mirabilos

PS: Thanks, Julien!
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...


--
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/alpine.deb.2.11.1409121610190.7...@tglase.lan.tarent.de

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[lee]

Daniel Dickinson  writes:

> I will add that for a distribution that claims to be about it's users,
> the systemd attitude of "We're *going* to use systemd so 'suck it up
> Buttercup' really stinks at a social level.

Debians' decision to support systemd already violates Debians' social
contract.  There already are too many packages with software totally
unrelated to an init system depending on systemd packages, so the users
cannot decide anymore that they do not want to use systemd.

A distribution that depends on a single piece of software, like on
systemd, is not in the interest of the users and removes their freedom,
and it's not "high quality material".  Supporting systemd has created a
design bug by which every individual package might still do their thing
technically right --- which makes it very difficult to file bug reports
because you can't tell which package to file the report against --- but
the overall outcome is a system depending on systemd.  It is bad design
that a package providing a functionality that doesn't have anything to
do with an init system should depend on a (package part of a) particular
init system.

All distributions that depend on systemd are broken by design.  Think
MCP, if you've seen Tron.


The decision to make systemd the future default init system was made by,
IIRC, like three or four people.  How many users were asked?  How
would making a decision like this in this way not violate Debians'
social contract?


-- 
Knowledge is volatile and fluid.  Software is power.


-- 
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/87bnqmyobn@yun.yagibdah.de

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Ben Hutchings]

On Wed, 2014-09-10 at 21:36 +, Nick Phillips wrote:
[...]
> Debian has a good and hard-earned reputation for not messing up
> sysadmins' changes; upgrading to systemd - however wonderful it is (and
> I confess to having no opinion on that) - without at least a debconf
> prompt of a reasonable priority telling them what is about to happen and
> offering a bailout, is guaranteed to lose us reputation and users.
[...]

I do agree that at least some kind of high-priority notice is needed.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.


signature.asc
Description: This is a digitally signed message part

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Josh Triplett]

Marcin Kulisz wrote:
> On 2014-09-09 18:23:58, Josh Triplett wrote:
> > Michael Biebl wrote:
> > > Together with the /lib/sysvinit/init fallback binary in sysvinit and
> > > (and optionally my patch getting merged for grub [1]), this should
> > > provide for a hopefully seamless upgrade experience.
> > 
> > Agreed, this seems like the best plan: avoid prompting in the common
> > case, prompt in cases that might cause problems, and provide an easy
> > fallback.
> > 
> > In particular, given that /etc/init.d/* scripts are typically conffiles,
> > we could easily detect if they've been directly changed, and if so, warn
> > about edits (with a list of edited files) and point to information on
> > applying those changes to the corresponding systemd services.
> 
> What about cases when init scripts doesn't come from any package but are
> crafted by hand?

Those init scripts will continue to work fine under systemd, as init
scripts, until the sysadmin gets around to rewriting them as systemd
services or similar.   The case that prompted my comment involved edited
init scripts overridden by (unedited) .service files, which we can
address by scanning for modified init scripts that have overriding
services, and prompting in that case.  However, that doesn't apply to
custom local init scripts.

- Josh Triplett


-- 
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/20140911082308.GA7775@thin

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Marc Haber]

On Thu, 11 Sep 2014 00:04:07 -0300, Martinx - ?
 wrote:
> Also, during Debian 8 installation, please, provide an "altinit" option (
>http://pyro.eu.org/debian/pool/main/d/debian-altinit/ ?), so, people can
>choose between systemd / sysvinit (before 1st boot). I know that it seems
>easy to just "apt-get install sysvinit-core" after install (1st boot) but,
>at least, Debian users will have an option to select a well tested, init
>system, while it is fully supported.

Please note that our init scripts are going to be a lot less reliable
in a world where only a fraction of our users will actually use them.

Many maintainers will reduce their priority on the to-do list.

Greetings
Marc
-- 
-- !! 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


--
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/e1xrynf-9k...@swivel.zugschlus.de

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Daniel Dickinson]

On 11/09/14 12:10 AM, Daniel Dickinson wrote:
> 
> I will add that for a distribution that claims to be about it's users,
> the systemd attitude of "We're *going* to use systemd so 'suck it up
> Buttercup' really stinks at a social level.

Especially since 'Free' is supposed to be 'as in Freedom not beer'.

This systemd thing is just as bad as any M$ corporate heavy-handedness.

Regards,

Daniel





signature.asc
Description: OpenPGP digital signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Daniel Dickinson]

For the heck of it, I will add that if in my job I pushed out crap like
Network Manager and Pulseaudio at the time of introduction as 'the
saviour of the Linux desktop' as a production release I would have fired
long ago.

Regards,

Daniel

On 11/09/14 12:10 AM, Daniel Dickinson wrote:
> 
> I will add that for a distribution that claims to be about it's users,
> the systemd attitude of "We're *going* to use systemd so 'suck it up
> Buttercup' really stinks at a social level.
> 
> Not to mention, as many have pointed out, transition to systemd is *not*
> going to be painless and without problems, in fact far from it.
> 
> This is going to worse than the pulseaudio and network manager ages of
> brokeness being forced on users before the systems are truly ready for
> full deployment.
> 
> Network Manager is just now, years later, getting bridge support, and it
> is still under heavy development because a lot of the time it doesn't
> work correctly.
> 
> Do we really need yet another pushed-before-ready-for-production
> 'solution' that drives people away from the Linux?
> 
> The reason I chose Debain over Ubuntu was that Ubuntu had (don't know
> about nowadays) a tendency to force things onto their users before they
> were properly and Debian at least took a more 'slow-and-steady' approach
> to improvements, and resisted upstart because it wasn't ready.
> 
> Why is systemd is suddenly so differnt?
> 
> I'm really not sure there are any sane distributions left at this point
> in the F/LOSS world.
> 
> Regards,
> 
> Daniel
> 




signature.asc
Description: OpenPGP digital signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Daniel Dickinson]

I will add that for a distribution that claims to be about it's users,
the systemd attitude of "We're *going* to use systemd so 'suck it up
Buttercup' really stinks at a social level.

Not to mention, as many have pointed out, transition to systemd is *not*
going to be painless and without problems, in fact far from it.

This is going to worse than the pulseaudio and network manager ages of
brokeness being forced on users before the systems are truly ready for
full deployment.

Network Manager is just now, years later, getting bridge support, and it
is still under heavy development because a lot of the time it doesn't
work correctly.

Do we really need yet another pushed-before-ready-for-production
'solution' that drives people away from the Linux?

The reason I chose Debain over Ubuntu was that Ubuntu had (don't know
about nowadays) a tendency to force things onto their users before they
were properly and Debian at least took a more 'slow-and-steady' approach
to improvements, and resisted upstart because it wasn't ready.

Why is systemd is suddenly so differnt?

I'm really not sure there are any sane distributions left at this point
in the F/LOSS world.

Regards,

Daniel



signature.asc
Description: OpenPGP digital signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Martinx - ジェームズ]

Hi!

 Yes, please... I vote +1 for *not silently replace* sysvinit by systemd,
when upgrading from Debian 7, to 8.

 Also, during Debian 8 installation, please, provide an "altinit" option (
http://pyro.eu.org/debian/pool/main/d/debian-altinit/ ?), so, people can
choose between systemd / sysvinit (before 1st boot). I know that it seems
easy to just "apt-get install sysvinit-core" after install (1st boot) but,
at least, Debian users will have an option to select a well tested, init
system, while it is fully supported.

 I'm seeing that, when with systemd, people are complaining that it does
not always work, so, it seems that, when with systemd, Debian will stop
working on a system that it always worked previously. Then, if people don't
have a option to select the `sysvinit-core` during the installation, this
will be a huge step back... They'll be forced to install Debian 7, then
upgrade to Debian 8, on those machines that systemd seems to not work.

 Also, the current Populatiry Contest is unfair, because it shows systemd
winning, when it is being pushed.

 I like the idea of a new init for this century BUT, since systemd
developers lack of social skills (read: "Linus already kicked those guys
from kernel dev"), it is wise to wait, at least, until ~2019, to replace
sysvinit / upstart, by systemd. I'll stick with Debian 8 + sysvinit (or
Ubuntu 14.04 with upstart), until ~2019.

 I'm not against change, I'm already using IPv6 and NFTables on a daily
basis...   ;-)

 BTW, if the `sysvinit-core` maintainers will maintain it for, lets say,
until kFreeBSD dies, so, why not let people choose between the two? Then,
we'll have time to see if this "systemd thing" will become a standard, or
not. It is safe to keep two options, until systemd guys proves to the open
source community, that they deserve more respect.

 Also, providing two init systems during Debian 8 cycle (or until kFreeBSD
remains around), *will calm down people all over the world*. People already
don't like change (not me), and a pushed change is even worse, it will make
them very unhappy / disappointed / betrayed.

Cheers!
Thiago

On 10 September 2014 18:36, Nick Phillips  wrote:

> On Wed, 2014-09-10 at 18:37 +0100, Ben Hutchings wrote:
> > On Wed, 2014-09-10 at 17:44 +0100, Noel Torres wrote:
> > > On Wednesday, 10 de September de 2014 03:12:16 Ben Hutchings escribió:
> > > > On Tue, 2014-09-09 at 21:24 +0100, Noel Torres wrote:
> > > > > On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen
> escribió:
> > > > > > ]] Carlos Alberto Lopez Perez
> > > > > >
> > > > > > > But if you don't (Is not uncommon to have servers on remote
> locations
> > > > > > > that are only accessible via ssh) and the machine don't boots
> > > > > > > properly you can find yourself in trouble.
> > > > > >
> > > > > > Then surely you test the upgrade before making it live, using kvm
> > > > > > -snapshot or similar functionality?
> > > > >
> > > > > This is simply not possible in physical live, productions servers
> on
> > > > > remote CPDs.
> > > >
> > > > In that case you test on your staging server first...
> > > >
> > > > Ben.
> > >
> > > IF you have an staging server... some clients simply do not pay for it.
> >
> > Then they already accepted the risk of extended downtime during an
> > upgrade.
>
> That doesn't, however, mean that it is acceptable for us to recklessly
> cause such downtime.
>
> It seems to me that there is clearly a large group of users for whom an
> automagic change in init system is desirable, and won't even be noticed.
>
> There is however also a large group of sysadmins for whom a
> noninteractive change of init system is a major, annoying issue. If our
> priority really is our users, then we can't brush this under the carpet
> with "you should have read the release notes" - and certainly not when
> the problem has been foreseen. That is simply not how you respond to
> someone you actually care about.
>
> Debian has a good and hard-earned reputation for not messing up
> sysadmins' changes; upgrading to systemd - however wonderful it is (and
> I confess to having no opinion on that) - without at least a debconf
> prompt of a reasonable priority telling them what is about to happen and
> offering a bailout, is guaranteed to lose us reputation and users.
>
> It doesn't matter whether we think that's reasonable or not, it is what
> will happen.
>
> So, is it actually feasible to provide such a prompt?
>
>
> Cheers,
>
>
> Nick
> --
> Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
> # These statements are mine, not those of the University of Otago
>

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Nick Phillips]

On Wed, 2014-09-10 at 18:37 +0100, Ben Hutchings wrote: 
> On Wed, 2014-09-10 at 17:44 +0100, Noel Torres wrote:
> > On Wednesday, 10 de September de 2014 03:12:16 Ben Hutchings escribió:
> > > On Tue, 2014-09-09 at 21:24 +0100, Noel Torres wrote:
> > > > On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen escribió:
> > > > > ]] Carlos Alberto Lopez Perez
> > > > > 
> > > > > > But if you don't (Is not uncommon to have servers on remote 
> > > > > > locations
> > > > > > that are only accessible via ssh) and the machine don't boots
> > > > > > properly you can find yourself in trouble.
> > > > > 
> > > > > Then surely you test the upgrade before making it live, using kvm
> > > > > -snapshot or similar functionality?
> > > > 
> > > > This is simply not possible in physical live, productions servers on
> > > > remote CPDs.
> > > 
> > > In that case you test on your staging server first...
> > > 
> > > Ben.
> > 
> > IF you have an staging server... some clients simply do not pay for it.
> 
> Then they already accepted the risk of extended downtime during an
> upgrade.

That doesn't, however, mean that it is acceptable for us to recklessly
cause such downtime.

It seems to me that there is clearly a large group of users for whom an
automagic change in init system is desirable, and won't even be noticed.

There is however also a large group of sysadmins for whom a
noninteractive change of init system is a major, annoying issue. If our
priority really is our users, then we can't brush this under the carpet
with "you should have read the release notes" - and certainly not when
the problem has been foreseen. That is simply not how you respond to
someone you actually care about.

Debian has a good and hard-earned reputation for not messing up
sysadmins' changes; upgrading to systemd - however wonderful it is (and
I confess to having no opinion on that) - without at least a debconf
prompt of a reasonable priority telling them what is about to happen and
offering a bailout, is guaranteed to lose us reputation and users.

It doesn't matter whether we think that's reasonable or not, it is what
will happen.

So, is it actually feasible to provide such a prompt?


Cheers,


Nick
-- 
Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Matthias Urlichs]

Hi,

Steve Langasek:
> On Wed, Sep 10, 2014 at 08:28:36PM +0100, Marcin Kulisz wrote:
> > What about cases when init scripts doesn't come from any package but are
> > crafted by hand?
> 
> It's straightforward to check for init scripts that are not owned by any
> packages.
> 
… and besides, systemd should just work with them.
If they descend from /etc/init.d/skeleton, that is.

Not having the requisite metadata at the top of the script might me a more
reliable indicator than not belonging to a package.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Steve Langasek]

On Wed, Sep 10, 2014 at 08:28:36PM +0100, Marcin Kulisz wrote:

> What about cases when init scripts doesn't come from any package but are
> crafted by hand?

> Those can not be easily detected and compared for changes, as they are not
> coming from any package and they may (and in some cases are) quite important
> for boot process.

It's straightforward to check for init scripts that are not owned by any
packages.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Marcin Kulisz]

On 2014-09-09 18:23:58, Josh Triplett wrote:
> Michael Biebl wrote:
> > Together with the /lib/sysvinit/init fallback binary in sysvinit and
> > (and optionally my patch getting merged for grub [1]), this should
> > provide for a hopefully seamless upgrade experience.
> 
> Agreed, this seems like the best plan: avoid prompting in the common
> case, prompt in cases that might cause problems, and provide an easy
> fallback.
> 
> In particular, given that /etc/init.d/* scripts are typically conffiles,
> we could easily detect if they've been directly changed, and if so, warn
> about edits (with a list of edited files) and point to information on
> applying those changes to the corresponding systemd services.

What about cases when init scripts doesn't come from any package but are
crafted by hand?

Those can not be easily detected and compared for changes, as they are not
coming from any package and they may (and in some cases are) quite important
for boot process.
-- 

|_|0|_|  |
|_|_|0| "Heghlu'Meh QaQ jajVam"  |
|0|0|0|  kuLa -  |

gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
3DF1 A4DF C732 4688 38BC F121 6869 30DD  58C3 38B3


signature.asc
Description: Digital signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Ben Hutchings]

On Wed, 2014-09-10 at 17:44 +0100, Noel Torres wrote:
> On Wednesday, 10 de September de 2014 03:12:16 Ben Hutchings escribió:
> > On Tue, 2014-09-09 at 21:24 +0100, Noel Torres wrote:
> > > On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen escribió:
> > > > ]] Carlos Alberto Lopez Perez
> > > > 
> > > > > But if you don't (Is not uncommon to have servers on remote locations
> > > > > that are only accessible via ssh) and the machine don't boots
> > > > > properly you can find yourself in trouble.
> > > > 
> > > > Then surely you test the upgrade before making it live, using kvm
> > > > -snapshot or similar functionality?
> > > 
> > > This is simply not possible in physical live, productions servers on
> > > remote CPDs.
> > 
> > In that case you test on your staging server first...
> > 
> > Ben.
> 
> IF you have an staging server... some clients simply do not pay for it.

Then they already accepted the risk of extended downtime during an
upgrade.

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


signature.asc
Description: This is a digitally signed message part

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Noel Torres]

On Wednesday, 10 de September de 2014 03:12:16 Ben Hutchings escribió:
> On Tue, 2014-09-09 at 21:24 +0100, Noel Torres wrote:
> > On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen escribió:
> > > ]] Carlos Alberto Lopez Perez
> > > 
> > > > But if you don't (Is not uncommon to have servers on remote locations
> > > > that are only accessible via ssh) and the machine don't boots
> > > > properly you can find yourself in trouble.
> > > 
> > > Then surely you test the upgrade before making it live, using kvm
> > > -snapshot or similar functionality?
> > 
> > This is simply not possible in physical live, productions servers on
> > remote CPDs.
> 
> In that case you test on your staging server first...
> 
> Ben.

IF you have an staging server... some clients simply do not pay for it.

Regards


signature.asc
Description: This is a digitally signed message part.

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Ondřej Surý]

On Wed, Sep 10, 2014, at 04:12, Ben Hutchings wrote:
> On Tue, 2014-09-09 at 21:24 +0100, Noel Torres wrote:
> > On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen escribió:
> > > ]] Carlos Alberto Lopez Perez
> > > 
> > > > But if you don't (Is not uncommon to have servers on remote locations
> > > > that are only accessible via ssh) and the machine don't boots properly
> > > > you can find yourself in trouble.
> > > 
> > > Then surely you test the upgrade before making it live, using kvm
> > > -snapshot or similar functionality?
> > 
> > This is simply not possible in physical live, productions servers on remote 
> > CPDs.
> 
> In that case you test on your staging server first...

Or at least be present at the facility when you do release to release+1
upgrade[+].

I have done really weird stuff with my non-production systems (like
cross-upgrading from Ubuntu devel to Debian stable), but for production
system you can broke your system even on kernel upgrades[*], so nothing
here is init system specific.

* - we had to carry a custom kernel at the time when Ubuntu backported
only a part of a patch and that broke a hw raid disk enumeration...

+ - And if you really can't be there or have a KVM or serial console,
you can always tweak the system to your likings before you do the
reboot. People, this is nothing new, please don't try to pretend it is
just because it's a init system.

Ondrej
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
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/1410354585.617786.165847321.72a52...@webmail.messagingengine.com

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Ben Hutchings]

On Tue, 2014-09-09 at 21:24 +0100, Noel Torres wrote:
> On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen escribió:
> > ]] Carlos Alberto Lopez Perez
> > 
> > > But if you don't (Is not uncommon to have servers on remote locations
> > > that are only accessible via ssh) and the machine don't boots properly
> > > you can find yourself in trouble.
> > 
> > Then surely you test the upgrade before making it live, using kvm
> > -snapshot or similar functionality?
> 
> This is simply not possible in physical live, productions servers on remote 
> CPDs.

In that case you test on your staging server first...

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


signature.asc
Description: This is a digitally signed message part

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Josh Triplett]

Michael Biebl wrote:
> Am 09.09.2014 17:15, schrieb Ansgar Burchardt:
> > Having only some systems switch to a different init system on upgrade
> > seems potentially confusing to me.
> 
> Agreed. We definitely should switch the machines on upgrades. There is a
> good reason why we also did it when switching to dependency based boot.
> 
>  That said, it would be nice if
> > systemd-sysv could check for common problems on installation and issue a
> > debconf warning, e.g. when not currently mounted entries are present in
> > /etc/fstab or when keyscripts for cryptsetup are used.
> 
> Nod. I'm planning to add such checks to systemd-sysv preinst (I think we
> already have a bug report open for that).
> 
> If it finds such issues on first installation, it will pop up a debconf
> prompt displaying the issues it found with some hints how to fix them
> and the choice to abort or continue with the installation.
> 
> Together with the /lib/sysvinit/init fallback binary in sysvinit and
> (and optionally my patch getting merged for grub [1]), this should
> provide for a hopefully seamless upgrade experience.

Agreed, this seems like the best plan: avoid prompting in the common
case, prompt in cases that might cause problems, and provide an easy
fallback.

In particular, given that /etc/init.d/* scripts are typically conffiles,
we could easily detect if they've been directly changed, and if so, warn
about edits (with a list of edited files) and point to information on
applying those changes to the corresponding systemd services.

- Josh Triplett


-- 
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/20140910010029.GA1693@jtriplet-mobl1

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Carlos Alberto Lopez Perez]

On 09/09/14 23:17, Tollef Fog Heen wrote:
>> That way of testing is completely unreliable when we are talking about
>> > low level stuff (kernel/udev/systemd).
> No, it's not.  It is able to emulate most of the concerns people are
> talking about in this thread.  Nobody has so far showed up and been
> worried about udev suddenly being incompatible, from what I've seen it's
> all about worries that things like buggy /etc/fstabs and similar
> problems prevent a clean boot.

I just gave a quick look at the list of systemd open bugs on the BTS
that can cause an unbootable system. At least #697962, #627949, #751585,
#754078 and #760848 are very difficult (if not impossible) to test
properly with the testing method you are proposing.



signature.asc
Description: OpenPGP digital signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Tollef Fog Heen]

]] Carlos Alberto Lopez Perez 

> On 09/09/14 22:18, Tollef Fog Heen wrote:
> > ]] Carlos Alberto Lopez Perez 
> > 
> >> But if you don't (Is not uncommon to have servers on remote locations
> >> that are only accessible via ssh) and the machine don't boots properly
> >> you can find yourself in trouble.
> > 
> > Then surely you test the upgrade before making it live, using kvm
> > -snapshot or similar functionality?
> > 
> 
> That way of testing is completely unreliable when we are talking about
> low level stuff (kernel/udev/systemd).

No, it's not.  It is able to emulate most of the concerns people are
talking about in this thread.  Nobody has so far showed up and been
worried about udev suddenly being incompatible, from what I've seen it's
all about worries that things like buggy /etc/fstabs and similar
problems prevent a clean boot.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87r3zksdd2@xoog.err.no

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Carlos Alberto Lopez Perez]

On 09/09/14 22:34, Carlos Alberto Lopez Perez wrote:
> I truly believe that making systemd the default without asking the user
> to test it first, is going to cause more breakage and angry users than
> doing it the other way.

s/making systemd the default/replacing the user init system with systemd on 
upgrades/



signature.asc
Description: OpenPGP digital signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Carlos Alberto Lopez Perez]

On 09/09/14 22:18, Tollef Fog Heen wrote:
> ]] Carlos Alberto Lopez Perez 
> 
>> But if you don't (Is not uncommon to have servers on remote locations
>> that are only accessible via ssh) and the machine don't boots properly
>> you can find yourself in trouble.
> 
> Then surely you test the upgrade before making it live, using kvm
> -snapshot or similar functionality?
> 

That way of testing is completely unreliable when we are talking about
low level stuff (kernel/udev/systemd).

I'm talking about physical (bare-metal) servers. Testing the upgrade on
a virtual machine does not help since the behavior of the system is
hardware dependent, and kvm can't reproduce that.

In any case, I'm not worried by the servers I manage. I know the current
status quo is to replace sysvinit with systemd on upgrades without
telling the user. So I'm ready to pin sysvinit if I think is a wiser choice.

What I'm trying to improve is the experience of the Debian users that
won't know that, and will upgrade their servers from Wheezy to Jessie.

I truly believe that making systemd the default without asking the user
to test it first, is going to cause more breakage and angry users than
doing it the other way.



signature.asc
Description: OpenPGP digital signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Noel Torres]

On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen escribió:
> ]] Carlos Alberto Lopez Perez
> 
> > But if you don't (Is not uncommon to have servers on remote locations
> > that are only accessible via ssh) and the machine don't boots properly
> > you can find yourself in trouble.
> 
> Then surely you test the upgrade before making it live, using kvm
> -snapshot or similar functionality?

This is simply not possible in physical live, productions servers on remote 
CPDs.

Regards


signature.asc
Description: This is a digitally signed message part.

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Tollef Fog Heen]

]] Carlos Alberto Lopez Perez 

> But if you don't (Is not uncommon to have servers on remote locations
> that are only accessible via ssh) and the machine don't boots properly
> you can find yourself in trouble.

Then surely you test the upgrade before making it live, using kvm
-snapshot or similar functionality?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/m2wq9c1r9s@rahvafeir.err.no

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Marvin Renich]

* Michael Biebl  [140909 11:43]:
> Am 09.09.2014 17:15, schrieb Ansgar Burchardt:
> > Having only some systems switch to a different init system on upgrade
> > seems potentially confusing to me.
> 
> Agreed. We definitely should switch the machines on upgrades. There is a
> good reason why we also did it when switching to dependency based boot.

I disagree.  Switching automatically might be okay if the sysadmin has
not made any local modifications to the boot process, or if you can be
sure that systemd is going to do the right thing with the sysadmin's
modifications, but preserving local sysadmin changes has alway been one
of the things that set Debian apart from other distros.  Please don't
mess this up now.

As for dependency based boot, it recognized when it could not handle it
properly (at least on one machine of mine) and fell back to manual
ordering, with an appropriate log message.  ISTR that I had two full
releases after upgrading to dependency based boot before I was forced to
fix it.  If systemd gives that kind of fallback, I will not complain.

...Marvin


-- 
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/20140909191638.gd3...@basil.wdw

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Marvin Renich]

* Mathieu Parent  [140909 09:15]:
> 2014-09-09 13:46 GMT+02:00 Carlos Alberto Lopez Perez :
> [...]
> > So, when upgrading from Wheezy to Jessie, we have three options:
> >
> > 1) Keep the user init system (sysvinit most probably)
> > 2) Upgrade to systemd after asking the user.
> > 3) Upgrade to systemd silently without asking the user.
> 
> 4) Upgrade to systemd silently without asking the user AND add a grub
> entry to use old init
> 
> This will provide the intended default with an extra compatibility
> layer (like the former grub1 to grub2 chain).

Debian packages at least two other families of boot loaders.  I am using
syslinux-efi on one machine, and have used lilo and elilo in the past.
Adding a grub entry will not adequately solve the problem.

...Marvin


-- 
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/20140909185819.gb3...@basil.wdw

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Marvin Renich]

* Ansgar Burchardt  [140909 11:16]:
> On 09/09/2014 16:59, Russ Allbery wrote:
> > I don't believe we should switch init systems on upgrade without at least
> > a prompt,
> 
> I think there are good arguments for both switching to the new default
> and not:

Perhaps, but not without giving the sysadmin a choice, unless you have
handled all the cases where the sysadmin has modified configuration
files such as /etc/inittab and scripts in /etc/init.d.

...Marvin


-- 
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/20140909190423.gc3...@basil.wdw

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Carlos Alberto Lopez Perez]

On 09/09/14 15:14, Mathieu Parent wrote:
> 2014-09-09 13:46 GMT+02:00 Carlos Alberto Lopez Perez :
> [...]
>> So, when upgrading from Wheezy to Jessie, we have three options:
>>
>> 1) Keep the user init system (sysvinit most probably)
>> 2) Upgrade to systemd after asking the user.
>> 3) Upgrade to systemd silently without asking the user.
> 
> 4) Upgrade to systemd silently without asking the user AND add a grub
> entry to use old init
> 
> This will provide the intended default with an extra compatibility
> layer (like the former grub1 to grub2 chain).
> 

This may be a good option when you have pre-boot access to the machine
(either physical access or with a KVM), so you can select an option on
the GRUB menu if things go wrong.

But if you don't (Is not uncommon to have servers on remote locations
that are only accessible via ssh) and the machine don't boots properly
you can find yourself in trouble.

When the transition to GRUB2 was made, it didn't replaced the previous
system (GRUB1) without asking the user. What it did was to add a new
(non default) entry on GRUB1 to chainload to GRUB2. The idea was that
the user could test the new system when he felt it was a good moment.
So, after checking that all worked as expected, he could make the new
system the default by executing a command: upgrade-from-grub-legacy. [1]


I wish something similar would be made for the switch to systemd:

1. Add a new entry on GRUB to boot with systemd (but leave the previous
init system as default).
2. Add a command upgrade-from-init-legacy or upgrade-to-systemd that
sets the option to boot with systemd as default.

That way the user can test to boot with systemd when he feels like is a
good moment, and if things work as expected he can make the switch
definitively by executing that command.





[1] https://wiki.debian.org/Grub#Upgrading_from_v1_to_v2



signature.asc
Description: OpenPGP digital signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Michael Biebl]

Am 09.09.2014 17:15, schrieb Ansgar Burchardt:
> Having only some systems switch to a different init system on upgrade
> seems potentially confusing to me.

Agreed. We definitely should switch the machines on upgrades. There is a
good reason why we also did it when switching to dependency based boot.

 That said, it would be nice if
> systemd-sysv could check for common problems on installation and issue a
> debconf warning, e.g. when not currently mounted entries are present in
> /etc/fstab or when keyscripts for cryptsetup are used.

Nod. I'm planning to add such checks to systemd-sysv preinst (I think we
already have a bug report open for that).

If it finds such issues on first installation, it will pop up a debconf
prompt displaying the issues it found with some hints how to fix them
and the choice to abort or continue with the installation.

Together with the /lib/sysvinit/init fallback binary in sysvinit and
(and optionally my patch getting merged for grub [1]), this should
provide for a hopefully seamless upgrade experience.


Michael


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757298
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Russ Allbery]

Ansgar Burchardt  writes:
> On 09/09/2014 17:01, Russ Allbery wrote:

>> The original plan was to have the question owned by some package that
>> could then switch the init symlink from one implementation to another.
>> That way, no abort is required.  I'm not sure if that survived contact
>> with reality, though, in the sense that I'm not sure how implementable
>> it is.

> The different init systems would have to be co-installable for this to
> work, however they are not.

They used to be.  Did we lose this somehow?

Oh, right, I remember the problem with this.  It was that various packages
required that systemd not only be installed but be running (for logind
reasons), and a dependency that can be satisfied by either init system
wasn't sufficient for this.  So you actually need systemd-shim to be
co-installable with systemd.  But I think that's now the case again,
correct?  In which case we could explore this again.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87iokwyfey@hope.eyrie.org

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Ansgar Burchardt]

On 09/09/2014 17:01, Russ Allbery wrote:
> Vincent Danjean  writes:
>> I agree with your analysis. However, how do you think we can ask the
>> user ? We can have a debconf question. However, whatever the answer is,
>> we must not return an error (i.e. aborting the upgrade). It is really a
>> pain to recover when this occurs.
> 
> The original plan was to have the question owned by some package that
> could then switch the init symlink from one implementation to another.
> That way, no abort is required.  I'm not sure if that survived contact
> with reality, though, in the sense that I'm not sure how implementable it
> is.

The different init systems would have to be co-installable for this to
work, however they are not.

For the planned fallback in grub to offer sysvinit on systemd systems, a
second copy of sysvinit's /sbin/init was included in a non-conflicting
package in a different location, but systemd's implementation of halt,
poweroff, ... would still be used (as these work with sysvinit's init as
well).

Ansgar


-- 
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/540f1a90.6050...@debian.org

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Ansgar Burchardt]

On 09/09/2014 16:59, Russ Allbery wrote:
> Carlos Alberto Lopez Perez  writes:
>> So, when upgrading from Wheezy to Jessie, we have three options:
> 
>> 1) Keep the user init system (sysvinit most probably)
>> 2) Upgrade to systemd after asking the user.
>> 3) Upgrade to systemd silently without asking the user.
[...]
>> I understand that we want users to switch to systemd, so proper testing
>> is done and bugs are reported. So option 2 is a good compromise. By
>> asking users, each one can decide if he wants to risk to try systemd or
>> not.
> 
> +1
> 
> I don't believe we should switch init systems on upgrade without at least
> a prompt, and given how easy it is to switch to systemd later, I think it
> would be best to not switch init systems at all during an upgrade unless
> forced to do so by other package dependencies (that may not happen at all
> if systemd-shim is good enough).

I think there are good arguments for both switching to the new default
and not: on one hand the migration will fail in some cases (and I doubt
we will find all of them), on the other hand I believe we want most
users to switch to the default init system, at least mid to long term.
Being the default means it will be better tested and provide a better
experience to (most) users.

We could delay the transition-on-upgrade by one release, but the
migration from sysvinit to systemd on a Jessie -> Jessie+1 upgrade will
probably end up less tested (though systemd itself would probably be
more tested by then).

Having only some systems switch to a different init system on upgrade
seems potentially confusing to me. That said, it would be nice if
systemd-sysv could check for common problems on installation and issue a
debconf warning, e.g. when not currently mounted entries are present in
/etc/fstab or when keyscripts for cryptsetup are used.

Ansgar


-- 
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/540f19af.3010...@debian.org

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Russ Allbery]

Vincent Danjean  writes:

> I agree with your analysis. However, how do you think we can ask the
> user ? We can have a debconf question. However, whatever the answer is,
> we must not return an error (i.e. aborting the upgrade). It is really a
> pain to recover when this occurs.

The original plan was to have the question owned by some package that
could then switch the init symlink from one implementation to another.
That way, no abort is required.  I'm not sure if that survived contact
with reality, though, in the sense that I'm not sure how implementable it
is.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87d2b4u9ch@hope.eyrie.org

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Russ Allbery]

Carlos Alberto Lopez Perez  writes:

> Most of our users don't care as long as their machines continue to work
> as expected after an upgrade.

> So, when upgrading from Wheezy to Jessie, we have three options:

> 1) Keep the user init system (sysvinit most probably)
> 2) Upgrade to systemd after asking the user.
> 3) Upgrade to systemd silently without asking the user.

> I believe that the actual option (number 3) is going to cause much
> breakage than the other alternatives.

> Also, as I already expressed on bug #747535 this is not something I
> would expect from Debian.

> I expect Debian to be rock solid stable and to have painless upgrades
> from one version to the next. The conservative (and safe) option is 1.

> I understand that we want users to switch to systemd, so proper testing
> is done and bugs are reported. So option 2 is a good compromise. By
> asking users, each one can decide if he wants to risk to try systemd or
> not.

+1

I don't believe we should switch init systems on upgrade without at least
a prompt, and given how easy it is to switch to systemd later, I think it
would be best to not switch init systems at all during an upgrade unless
forced to do so by other package dependencies (that may not happen at all
if systemd-shim is good enough).

We can prominantly document in the release notes how to switch to systemd
and encourage our users to do so, but there are enough differences in
behavior and enough conffiles that sysvinit honors and systemd doesn't
that I don't think we should just plow ahead without being clear about
what's going on.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87k35cu9ei@hope.eyrie.org

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Russ Allbery]

Samuel Thibault  writes:

> When I got "upgraded" to systemd on july, my system was completely
> misbehaving for several reasons related to my configuration:

> - I had an ISO mount in my fstab, whose file didn't exist any more,
> sysvinit never complained about it, systemd just stopped at boot.

Separate from the question of behavior on upgrades, I think we need to do
something about this before the jessie release.  There have been multiple
bug reports against openssh about its /run directory not being created
properly, which are due to this same issue.

Technically, those mounts need nofail if you don't care if they fail, but
sysvinit clearly never cared, so there are a lot of people out there with
failing mounts that they've just been ignoring.  When they install
systemd, the system then stops working in confusing ways.  I'm tempted to
say that installing systemd from a sysvinit system should mark anything
that isn't mounted at the time of the upgrade "nofail".

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87oauou9j7@hope.eyrie.org

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Ondřej Surý]

On Tue, Sep 9, 2014, at 15:14, Mathieu Parent wrote:
> 4) Upgrade to systemd silently without asking the user AND add a grub
> entry to use old init

I like this approach very much since it's least intrusive to the upgrade
process, but provides a emergency fallback in default installation.

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
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/1410272574.2370157.165422265.73c93...@webmail.messagingengine.com

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Mathieu Parent]

2014-09-09 15:14 GMT+02:00 Mathieu Parent :
> 2014-09-09 13:46 GMT+02:00 Carlos Alberto Lopez Perez :
> [...]
>> So, when upgrading from Wheezy to Jessie, we have three options:
>>
>> 1) Keep the user init system (sysvinit most probably)
>> 2) Upgrade to systemd after asking the user.
>> 3) Upgrade to systemd silently without asking the user.
>
> 4) Upgrade to systemd silently without asking the user AND add a grub
> entry to use old init

Oh. Michael Biebl already thought about it: #757298

Regards
-- 
Mathieu


-- 
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/CAFX5sbwLHCTnw8KXseERN8bO05U6VfPBgLKzdWX=gfmerem...@mail.gmail.com

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Mathieu Parent]

2014-09-09 13:46 GMT+02:00 Carlos Alberto Lopez Perez :
[...]
> So, when upgrading from Wheezy to Jessie, we have three options:
>
> 1) Keep the user init system (sysvinit most probably)
> 2) Upgrade to systemd after asking the user.
> 3) Upgrade to systemd silently without asking the user.

4) Upgrade to systemd silently without asking the user AND add a grub
entry to use old init

This will provide the intended default with an extra compatibility
layer (like the former grub1 to grub2 chain).

Regards

-- 
Mathieu


-- 
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/CAFX5sbzQKq9AJ-L5NR8Vn2y=ZAk=vwphq8aimsn9i+k76l_...@mail.gmail.com

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Samuel Thibault]

Ondřej Surý, le Tue 09 Sep 2014 13:10:48 +0200, a écrit :
> > And I'm saying that I don't think this is an isolated case,
> 
> And I'm saying that all we have is anecdotal evidence

Our uni lab has switched to systemd, 20% of the machines do not boot.
The admin is currently looking at what the difference could be between
them to expain such a difference (same hardware, supposed-to-be same
software installation).

Samuel


-- 
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/20140909121931.gx3...@type.bordeaux.inria.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Samuel Thibault]

Samuel Thibault, le Tue 09 Sep 2014 14:11:28 +0200, a écrit :
> I have made a quick poll among various people here and there, there is
> no real consensus, either on switching to systemd by default or keeping
> with sysvinit by default. So it seems to me a question during upgrade is
> needed.

(more precisely, among 16 people, 5 for systemd, 9 for sysv, 2 don't
speak)

Samuel


-- 
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/20140909121651.gs3...@type.bordeaux.inria.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Samuel Thibault]

Matthias Urlichs, le Tue 09 Sep 2014 13:49:54 +0200, a écrit :
> Samuel Thibault:
> > > So please fill a bug for every breakage you will encounter, so it
> > > can be either fixed or documented.
> > 
> > There will be dozens of them then. Will they really be fixed in time for
> > Jessie?
> > 
> We don't know yet. Would you rather have bugs which are not even reported,
> and operate from _really_ incomplete knowledge?

Well, I thought it was already well-known that quite a few regressions
are being brought, but apparently it's not. I'll just file bugs then.

> > When we upgraded from grub1 to grub2, we have let the users decide when
> > they actually do the switch, so they can handle it independently from
> > the system upgrade. Why not doing the same here?
> 
> Nobody said that we wouldn't let the user decide.
> That's different from what some people here seem to want, which is not
> do anything at all until the admin explicitly installs systemd-sysv.

No, I'm not asking this.  I'm asking not to upgrade to systemd silently.
Sure, people are supposed to read release notes.  But the release notes
can't mention all the differences of behavior brought by systemd that
may hurt the admin very badly (and far from everybody read release notes
unfortunately).

I have made a quick poll among various people here and there, there is
no real consensus, either on switching to systemd by default or keeping
with sysvinit by default. So it seems to me a question during upgrade is
needed.

Samuel


-- 
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/20140909121128.gr3...@type.bordeaux.inria.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Vincent Danjean]

On 09/09/2014 13:46, Carlos Alberto Lopez Perez wrote:
> So, when upgrading from Wheezy to Jessie, we have three options:
> 
> 1) Keep the user init system (sysvinit most probably)
> 2) Upgrade to systemd after asking the user.
> 3) Upgrade to systemd silently without asking the user.
[...]
> I understand that we want users to switch to systemd, so proper testing
> is done and bugs are reported. So option 2 is a good compromise. By
> asking users, each one can decide if he wants to risk to try systemd or not.

I agree with your analysis. However, how do you think we can ask
the user ? We can have a debconf question. However, whatever the answer
is, we must not return an error (i.e. aborting the upgrade). It is
really a pain to recover when this occurs.

> For example: I will try systemd on my laptop, but not on a remote server
> that only is accessible via ssh.

I agree with you.

  Regards,
Vincent.

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/540eee09.7090...@free.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Vincent Danjean]

On 09/09/2014 13:10, Ondřej Surý wrote:
> And I'm saying that all we have is anecdotal evidence and we all
> know what we step into when we run our systems on jessie or sid.
> So please fill a bug for every breakage you will encounter, so it
> can be either fixed or documented.

Did you look at the current bug list for systemd ?
According to the PTS page, there are already 160 of them.

>> I believe most our users prefer to stay with sysvinit when upgrading from 
>> wheezy
> 
> And I believe that most our users don't care.

I agree, but if something breaks.

I consider myself having a not so bad level in system and
Linux administration. And I'm not able to fix the boot of my server.
I'm not even able to know exactly what is going wrong with it.
  Systemd have really interesting features, that why I'm testing it
and installing as much as I can. But the fact is that I not able
to deal with all the problems occurring when switching from sysv
on my own systems. So, I'm really confident that I wont be the only
one.

As others already tell, as much as possible, my opinion is that the
init switch should be done independently of the upgrade, and only
when explicitly requested by the administrator.
  The release note can emphasis that, for a better user experience,
the admin should really consider to do the switch of the init system
after the upgrade, for example by running
"apt-get install systemd-sysv" when the upgrade (and, if possible, a
reboot) is done.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/540eecf3.3090...@free.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Matthias Urlichs]

Hi,

Samuel Thibault:
> > So please fill a bug for every breakage you will encounter, so it
> > can be either fixed or documented.
> 
> There will be dozens of them then. Will they really be fixed in time for
> Jessie?
> 
We don't know yet. Would you rather have bugs which are not even reported,
and operate from _really_ incomplete knowledge?

> When we upgraded from grub1 to grub2, we have let the users decide when
> they actually do the switch, so they can handle it independently from
> the system upgrade. Why not doing the same here?
> 
Nobody said that we wouldn't let the user decide. That's different from
what some people here seem to want, which is not do anything at all until
the admin explicitly installs systemd-sysv.

-- 
-- Matthias Urlichs


-- 
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/20140909114954.gq21...@smurf.noris.de

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Carlos Alberto Lopez Perez]

On 09/09/14 13:10, Ondřej Surý wrote:
>> > I believe most our users prefer to stay with sysvinit when upgrading from 
>> > wheezy
> And I believe that most our users don't care. But I as a maintainer
> and operator of several daemons I really do care to have as most
> unified environment for debugging the problems.

Most of our users don't care as long as their machines continue to work
as expected after an upgrade.

So, when upgrading from Wheezy to Jessie, we have three options:

1) Keep the user init system (sysvinit most probably)
2) Upgrade to systemd after asking the user.
3) Upgrade to systemd silently without asking the user.

I believe that the actual option (number 3) is going to cause much
breakage than the other alternatives.

Also, as I already expressed on bug #747535 this is not something I
would expect from Debian.

I expect Debian to be rock solid stable and to have painless upgrades
from one version to the next. The conservative (and safe) option is 1.

I understand that we want users to switch to systemd, so proper testing
is done and bugs are reported. So option 2 is a good compromise. By
asking users, each one can decide if he wants to risk to try systemd or not.

For example: I will try systemd on my laptop, but not on a remote server
that only is accessible via ssh.



signature.asc
Description: OpenPGP digital signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Samuel Thibault]

Samuel Thibault, le Tue 09 Sep 2014 13:19:31 +0200, a écrit :
> > > I believe most our users prefer to stay with sysvinit when upgrading from 
> > > wheezy
> > 
> > And I believe that most our users don't care.
> 
> I believe most of our users care about an upgrade to Jessie that doesn't
> bring regressions.

It is also a matter of least surprise. Systemd behaves differently in a
fair amount of ways.

Samuel


-- 
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/20140909112323.gi3...@type.bordeaux.inria.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Samuel Thibault]

Ondřej Surý, le Tue 09 Sep 2014 13:10:48 +0200, a écrit :
> On Tue, Sep 9, 2014, at 11:54, Samuel Thibault wrote:
> > Ondřej Surý, le Tue 09 Sep 2014 11:47:38 +0200, a écrit :
> > > And you are saying that you can do all those tweaks, but you cannot
> > > pin systemd-sysv to not install?
> > 
> > No, I'm saying that if I hadn't noticed "systemd" among the upgrades, I
> > would have gotten all these changes all of a sudden without asking for
> > them. That can be pretty bad for the serial console access.
> 
> Also broken libdb upgrade in hamm (I think) broke my system beyond
> repair...  It's testing (and unstable), it's expected to have some
> undocumented breakages. That's the sole reason to have the testing
> and unstable in first place. To find the problems, fix them and if
> that's
> not possible (for various reasons[*]) then we should document that
> in the release notes.

Sure. But I don't ever see us discovering all problems and fix them with
just the freeze period.

> > And I'm saying that I don't think this is an isolated case,
> 
> And I'm saying that all we have is anecdotal evidence and we all
> know what we step into when we run our systems on jessie or sid.
> So please fill a bug for every breakage you will encounter, so it
> can be either fixed or documented.

There will be dozens of them then. Will they really be fixed in time for
Jessie?

> > I believe most our users prefer to stay with sysvinit when upgrading from 
> > wheezy
> 
> And I believe that most our users don't care.

I believe most of our users care about an upgrade to Jessie that doesn't
bring regressions.

When we upgraded from grub1 to grub2, we have let the users decide when
they actually do the switch, so they can handle it independently from
the system upgrade. Why not doing the same here?

Samuel


-- 
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/20140909111931.gf3...@type.bordeaux.inria.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Ondřej Surý]

On Tue, Sep 9, 2014, at 11:54, Samuel Thibault wrote:
> Ondřej Surý, le Tue 09 Sep 2014 11:47:38 +0200, a écrit :
> > And you are saying that you can do all those tweaks, but you cannot
> > pin systemd-sysv to not install?
> 
> No, I'm saying that if I hadn't noticed "systemd" among the upgrades, I
> would have gotten all these changes all of a sudden without asking for
> them. That can be pretty bad for the serial console access.

Also broken libdb upgrade in hamm (I think) broke my system beyond
repair...  It's testing (and unstable), it's expected to have some
undocumented breakages. That's the sole reason to have the testing
and unstable in first place. To find the problems, fix them and if
that's
not possible (for various reasons[*]) then we should document that
in the release notes.

> And I'm saying that I don't think this is an isolated case,

And I'm saying that all we have is anecdotal evidence and we all
know what we step into when we run our systems on jessie or sid.
So please fill a bug for every breakage you will encounter, so it
can be either fixed or documented.

> I believe most our users prefer to stay with sysvinit when upgrading from 
> wheezy

And I believe that most our users don't care. But I as a maintainer
and operator of several daemons I really do care to have as most
unified environment for debugging the problems.

Ondrej
* - f.e. I am quite sure I broke some php5-cgi deployments by enforcing
the more strict security...
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
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/1410261048.2317496.165348985.0bb28...@webmail.messagingengine.com

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Ondřej Surý]

On Tue, Sep 9, 2014, at 09:11, Samuel Thibault wrote:
> > You cannot have an MTA without configuring it, and nobody even tried to
> > implement auto-migration of the old default mailer's configuration to the
> > new one. Also, we didn't switch to a different default mailer because the
> > new one offered a heap of features and infrastructure which the other
> > lacked. None of this applies to systemd.
> 
> This does apply to systemd too.
> 
> When I got "upgraded" to systemd on july, my system was completely
> misbehaving for several reasons related to my configuration:
> 
> - I had an ISO mount in my fstab, whose file didn't exist any more,
> sysvinit never complained about it, systemd just stopped at boot.
> - I had several bind mounts, forming loops, which has never been a
> problem for sysvinit, but it made systemd take ages to boot & shutdown
> because it'd crazily bring thousands of lines in /proc/mounts, details
> in #755674.
> - I had tweaks in /etc/inittab to get the gettys earlier than
> daemon starts, in case those get stuck etc., this does not work any
> more with systemd.
> - I had tweaks in /etc/inittab to have more gettys on the text console,
> this does not work with systemd any more.
> - I had tweaks in /etc/inittab to shutdown instead of reboot when I
> press ctrl-alt-backspace, this does not work with systemd any more.

And you are saying that you can do all those tweaks, but you cannot
pin systemd-sysv to not install?

Let's just document the way how to prevent systemd-sysv to install
in release notes and switch the default init to systemd as Debian
maintainers who would like to keep their sanity would do.

Ondrej
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
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/1410256058.2294779.165322957.7f81e...@webmail.messagingengine.com

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Samuel Thibault]

Ondřej Surý, le Tue 09 Sep 2014 11:47:38 +0200, a écrit :
> switch the default init to systemd as Debian
> maintainers who would like to keep their sanity would do.

I have lost my sanity about system boot & shutdown since when I have
switched to systemd. Really.

Samuel


-- 
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/20140909095640.gs3...@type.bordeaux.inria.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Samuel Thibault]

Ondřej Surý, le Tue 09 Sep 2014 11:47:38 +0200, a écrit :
> And you are saying that you can do all those tweaks, but you cannot
> pin systemd-sysv to not install?

No, I'm saying that if I hadn't noticed "systemd" among the upgrades, I
would have gotten all these changes all of a sudden without asking for
them. That can be pretty bad for the serial console access.

And I'm saying that I don't think this is an isolated case, I believe
most our users prefer to stay with sysvinit when upgrading from wheezy
to jessie, at least to keep the behavior of their machine as it is, and
then consider switching to systemd. Collapsing both is asking for
regressions and angry users (they already tell me bad Debian jokes about
the upgrade to systemd).

Samuel


-- 
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/20140909095444.gp3...@type.bordeaux.inria.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Samuel Thibault]

> You cannot have an MTA without configuring it, and nobody even tried to
> implement auto-migration of the old default mailer's configuration to the
> new one. Also, we didn't switch to a different default mailer because the
> new one offered a heap of features and infrastructure which the other
> lacked. None of this applies to systemd.

This does apply to systemd too.

When I got "upgraded" to systemd on july, my system was completely
misbehaving for several reasons related to my configuration:

- I had an ISO mount in my fstab, whose file didn't exist any more,
sysvinit never complained about it, systemd just stopped at boot.
- I had several bind mounts, forming loops, which has never been a
problem for sysvinit, but it made systemd take ages to boot & shutdown
because it'd crazily bring thousands of lines in /proc/mounts, details
in #755674.
- I had tweaks in /etc/inittab to get the gettys earlier than
daemon starts, in case those get stuck etc., this does not work any
more with systemd.
- I had tweaks in /etc/inittab to have more gettys on the text console,
this does not work with systemd any more.
- I had tweaks in /etc/inittab to shutdown instead of reboot when I
press ctrl-alt-backspace, this does not work with systemd any more.

If I had tweaks in /etc/inittab to enable serial consoles, would the
upgrade to systemd kept them working?  I haven't found code about this.
This is *especially* important for servers, for which that might be the
only way to access the system without having to take the bike to get to
the datacenter.

Of course, these are all bugs that could be fixed in systemd.  I however
doubt we can discover (and fix) them all for Jessie, and I strongly
doubt that the first item of my list (which is more a difference of
behavior than a bug) will be ever be fixed actually.

If it ain't broken, don't break it.

Samuel


-- 
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/20140909071103.ga2...@type.youpi.perso.aquilenet.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Holger Levsen]

Hi Jonas,

On Montag, 8. September 2014, Jonas Smedegaard wrote:
> I did not file a bugreport about that - where could I?

upgrade-reports seems to be the pseudo package you want. See 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=upgrade-reports :-)


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Cameron Norman]

El lun, 8 de sep 2014 a las 9:07 , Matthias Urlichs 
 escribió:

Hi,

Vincent Danjean:
 If I recall correctly, when Debian switched the default MTA, 
upgrades

 did not change the already installed.


You cannot have an MTA without configuring it, and nobody even tried 
to
implement auto-migration of the old default mailer's configuration to 
the
new one. Also, we didn't switch to a different default mailer because 
the

new one offered a heap of features and infrastructure which the other
lacked.

None of this applies to systemd.


I do not think that the reasons for switching are at all relevant. 
These examples are unanimously pointing to defaults only being defaults 
for new installation.


I think most people would expect that if XFCE remained the default 
desktop for Jessie, then GNOME users should not be switched over 
without even being asked. But this is not even a good example. What we 
are doing here is switching **everyone**, even those who are using a 
custom /sbin/init in their own repo or Upstart.


Furthermore, this switching is being done far more often than just at 
upgrade time: everytime a user installs something that depends or 
recommends libpam-systemd (indirectly or directly), he or she currently 
have to double check that their init system is not being switched out 
from under them. Install CUPS? Better know that you have to install 
systemd-shim if you want to keep your init system...


The fact is that most "defaults" changes do not modify current user's 
systems (MTA, syslog, desktop environment), and they definitely do not 
do so without asking about it first (see /bin/dash).


Even if you do want to change it at upgrade time silently, the 
systemd-sysv | systemd-shim bit does way more than that, and it does so 
constantly and without any immediate guidance (i.e. install 
systemd-shim).


A couple ways to make this better would be to add a message in 
systemd-sysv saying that the system is being switched over (and that 
installing systemd-shim may prevent this, at the cost of a less 
complete/solid/whatever logind implementation), just switching the 
dependencies around, or using virtual packages for logind dependencies 
(since apt knows what is the best decision already).


Please consider the above prospective actions, and give feedback or 
results.


Thank you for your time and effort,
--
Cameron Norman

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Jonas Smedegaard]

Quoting Vincent Danjean (2014-09-08 21:37:14)
> On 08/09/2014 18:07, Matthias Urlichs wrote:
>> Vincent Danjean:
>>> If I recall correctly, when Debian switched the default MTA, 
>>> upgrades did not change the already installed.
>>
>> You cannot have an MTA without configuring it, and nobody even tried 
>> to implement auto-migration of the old default mailer's configuration 
>> to the new one. Also, we didn't switch to a different default mailer 
>> because the new one offered a heap of features and infrastructure 
>> which the other lacked.
>>
>> None of this applies to systemd.
>
> I'm under the impression that systemd supporters think too much that 
> the configuration will be transparently migrated from sysinit to 
> systemd.
>   Yes, systemd support sysv init scripts
>   Yes (probably, not tested), systemd respect admin choice to
> desactivate service if done with the update-rc.d command.
> 
>   But, as soon as systemd has unit files that replaces init scripts, 
> these ones are not used anymore. And any customization (such as "exit 
> 0") done in them is then lost. I'm wrong ?
>   It occurs to me several times when upgrading various servers. 
> Sometimes, the fix is relatively easy (create a new service file that 
> does what is missing, properly disabling a service instead of putting 
> "exit 0" in the init script, ...) And sometimes I do not succeed at 
> all (see #760848 that I already mentioned).
>   I try to switch to systemd as soon as I upgrade to testing, as I 
> found systemd better that sysv. It is also a way for me to learn 
> systemd. When standard init files have not been modified, the upgrade 
> is indeed paintless. But when there is a problem, I find very 
> difficult to fix it for now. And nearly any customization of init 
> scripts is lost without a word during the upgrade. Enabling the 
> debug-shell service and redirecting the boot log to a virtual console 
> save me several times.

Good point.

I have had a similar experience on a home server running MPD, where I 
had tweaked the init file to run MPD under a different user.

When that system auto-switched to systemd my audio setup was broken.  No 
warnings about changes to conffiles during the upgrade - because the old 
files was simply skipped and instead system files was used instead.

I did not file a bugreport about that - where could I?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Marc Haber]

On Mon, 8 Sep 2014 18:07:18 +0200, Matthias Urlichs
 wrote:
>Vincent Danjean:
>> If I recall correctly, when Debian switched the default MTA, upgrades
>> did not change the already installed.
>
>You cannot have an MTA without configuring it, and nobody even tried to
>implement auto-migration of the old default mailer's configuration to the
>new one.

Actually, the exim4 maintainer scripts parsed the exim 3 configuration
files to give its debconf prompt a locally relevant meaning.

Greetings
Marc
-- 
-- !! 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


--
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/e1xr5mc-0007um...@swivel.zugschlus.de

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Vincent Danjean]

On 08/09/2014 18:07, Matthias Urlichs wrote:
> Hi,
> 
> Vincent Danjean:
>> If I recall correctly, when Debian switched the default MTA, upgrades
>> did not change the already installed.
> 
> You cannot have an MTA without configuring it, and nobody even tried to
> implement auto-migration of the old default mailer's configuration to the
> new one. Also, we didn't switch to a different default mailer because the
> new one offered a heap of features and infrastructure which the other
> lacked.
> 
> None of this applies to systemd.

I'm under the impression that systemd supporters think too much that
the configuration will be transparently migrated from sysinit to
systemd.
  Yes, systemd support sysv init scripts
  Yes (probably, not tested), systemd respect admin choice to
desactivate service if done with the update-rc.d command.

  But, as soon as systemd has unit files that replaces init scripts,
these ones are not used anymore. And any customization (such as "exit 0")
done in them is then lost. I'm wrong ?
  It occurs to me several times when upgrading various servers.
Sometimes, the fix is relatively easy (create a new service file
that does what is missing, properly disabling a service instead
of putting "exit 0" in the init script, ...)
And sometimes I do not succeed at all (see #760848 that I already
mentioned).
  I try to switch to systemd as soon as I upgrade to testing,
as I found systemd better that sysv. It is also a way for me
to learn systemd. When standard init files have not been modified,
the upgrade is indeed paintless. But when there is a problem,
I find very difficult to fix it for now. And nearly any customization
of init scripts is lost without a word during the upgrade. Enabling
the debug-shell service and redirecting the boot log to a virtual
console save me several times.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/540e056a.3040...@free.fr

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Theodore Ts'o]

On Sat, Sep 06, 2014 at 09:39:05AM -0700, Russ Allbery wrote:
> Note also that a few of those things (udev, adduser, and
> libdevmapper1.02.1 for example) are likely to be on any non-chroot system
> already since they're either dependencies of other things (such as grub
> for libdevmapper1.02.1) or are already in use regardless of the init
> system (udev).  So for the case of a small embedded system that's
> nonetheless running the full kernel + bootloader stack, I suspect the
> delta is even smaller.

I can give a hard data point.  A month ago, debootstrap in Jessie was
still giving you a sysvinit based system.  I build a VM that has a
minimal debootstrap, with a very small set of packages[1], plus
xfstests.  In early August, this VM was 54 megabytes

[1] 
https://git.kernel.org/cgit/fs/ext2/xfstests-bld.git/tree/kvm-xfstests/test-appliance/packages

This past weekend, I spent a good part of the weekend updating
kvm-xfstests to use systemd, since debootstrap now forces systemd on
you, and so I decided to bite the bullet and convert to systemd.

This was not quite trivial, because I depended on being able to run
xfstests in /etc/rc.local, and serial console getty would start up
before /etc/rc.local had finished, and then HUP the entier xfstests
run.  Still, after fighting with the sysvinit unit scripts, I finally
managed to get it all working again.

The resulting VM image was 62 megabytes[2], or about 15% larger.
Since the VM image generation is completely automated[3], I'm
confident that this is an apples-to-apples comparison.

[2] https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests/
[3] 
https://git.kernel.org/cgit/fs/ext2/xfstests-bld.git/tree/kvm-xfstests/test-appliance/gen-image

Cheers,

- Ted

P.S.  Note what is required to be fully GPL compliant when
distributing a VM image[4].  You need to be able to identify the
precise sources for *all* of the GPL'ed packages used for a particular
VM image, and it's something that most people don't bother to do.  To
(loosely) quote Bradley Kuhn from his recent talk at LinuxCon, "it's
all too easy to accidentally violate the GPL; I'm sure I've done it
from time to time".

[4] ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests/README


-- 
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/20140908183223.ga6...@thunk.org

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Jonathan Dowland]

On Sat, Sep 06, 2014 at 02:33:04PM +0200, Adam Borowski wrote:
> Ok, so let's quantify the view of sysadmins somehow.

This is a complete waste of time and I expect better of you in particular.


-- 
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/20140908161425.ga24...@bryant.redmars.org

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Matthias Urlichs]

Hi,

Vincent Danjean:
> If I recall correctly, when Debian switched the default MTA, upgrades
> did not change the already installed.

You cannot have an MTA without configuring it, and nobody even tried to
implement auto-migration of the old default mailer's configuration to the
new one. Also, we didn't switch to a different default mailer because the
new one offered a heap of features and infrastructure which the other
lacked.

None of this applies to systemd.

-- 
-- Matthias Urlichs


-- 
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/20140908160718.gp21...@smurf.noris.de

upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Vincent Danjean]

On 08/09/2014 15:27, Noel Torres wrote:
> On Sunday, 7 de September de 2014 23:45:12 David Weinehall escribió:
>> On Fri, Sep 05, 2014 at 12:37:12PM -0700, Cameron Norman wrote:
>>> On Fri, Sep 5, 2014 at 1:57 AM, Josselin Mouette  wrote:
 Noel Torres wrote:
> So we are clearly failing to follow the least surprise (for the user)
> path.
>
> Should not logind depend on systemd-shim | systemd-sysv instead?

 No. Systemd is the default init system. The default dependencies should
 reflect that.
>>>
>>> It has already been explained that it being the default makes the
>>> order switching irrelevant for what you recommend. If people are using
>>> the default init, the dependency will already be satisfied and life
>>> will not be disrupted. The same thing should happen if people are
>>> using a different init: that decision should be maintained unless they
>>> manually uninstall the package that satisfies the init package's
>>> dependency.
>>
>> Most Debian systems aren't using sysvinit by active choice, but because
>> it was the default when they installed their machines, so this argument
>> doesn't really make sense.
> 
> Does that mean that we can happily break their hand made configurations for 
> their was-default current init system?
> 
> If our priorities are free software and _our users_ of course not.

If I recall correctly, when Debian switched the default MTA, upgrades
did not change the already installed.
When Debian switched the default syslog implementation (to rsyslog),
upgrades did not change already installed syslog implementation.
  Unless some special dependencies require it, upgrades must not
change the init system. I tried systemd on one of my servers. As the
init was customized for a complex setup that I'm unable to map into
systemd configuration, it is now a pain to boot it (#760848).

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/540dc155.7020...@free.fr

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Simon McVittie]

On 08/09/14 14:44, Noel Torres wrote:
> Example: having EMC Networker server softare for backups in a sysvinit 
> machine 
> is (relatively) easy, because the scripts for starting and stopping the 
> services are (quite) standard (but very complicated) sysv scripts.

systemd is compatible with LSB (i.e. sysvinit) init scripts. So is Upstart.

If they weren't, Debian wouldn't have been able to consider them as
possibilities for a default init system, given the significant number of
LSB init scripts that don't have a corresponding systemd unit or Upstart
job.

(This horse is dead; if you insist on continuing to beat it, please at
least check that you aren't aiming at a nearby straw man instead :-)

S


-- 
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/540dba2b.8040...@debian.org

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Noel Torres]

On Sunday, 7 de September de 2014 16:11:02 Matthias Urlichs escribió:
> Hi,
> 
> Chris Bannister:
> > > If technically feasible, that would be a far better safety net (just
> > > tell people to boot with init=/sbin/sysvinit if they run into a
> > > problem) than an "oh dear, it's so dangerous that we don't even
> > > install it by default" message. :-/
> > 
> > Surely, it should be an OPT-IN choice, not an OPT-OUT one? I'm talking
> > upgrades here, not new installs.
> 
> I am talking "if we decide to use a configurable symlink, then
> surely systemd will have the highest priority". [*]
> 
> Yes, that does mean that, if you do not do anything else, your system will
> boot with systemd. Which IMHO is as it should be.

I do not challenge systemd being the default, but I want my own systems with 
configured sysvinit scripts not to be switched.

Example: having EMC Networker server softare for backups in a sysvinit machine 
is (relatively) easy, because the scripts for starting and stopping the 
services are (quite) standard (but very complicated) sysv scripts. Migrating 
that machine to systemd just renders tens of thousands of euros useless 
because the backup server software will not start.
> 
> Quite frankly: If you're savvy enough to do something to your init setup
> that is no longer supported, and at the same time stupid enough to upgrade
> to Jessie without reading the release notes _and_ ignore systemd-sysv's
> debconf notice (which doesn't exist yet, but should probably be added),
> then that's your own damn fault.

Frankly I know lots of people who fall in that category (savvy enough and what 
you dismissingly call "stupid enough") who would benefit a lot for that debconf 
notice. We should make sure that it helps also people doing remote upgrades on 
console command line.

Regards

Noel
er Envite


signature.asc
Description: This is a digitally signed message part.

Re: Cinnamon environment now available in testing

[Noel Torres]

On Sunday, 7 de September de 2014 23:45:12 David Weinehall escribió:
> On Fri, Sep 05, 2014 at 12:37:12PM -0700, Cameron Norman wrote:
> > On Fri, Sep 5, 2014 at 1:57 AM, Josselin Mouette  wrote:
> > > Noel Torres wrote:
> > >> So we are clearly failing to follow the least surprise (for the user)
> > >> path.
> > >> 
> > >> Should not logind depend on systemd-shim | systemd-sysv instead?
> > > 
> > > No. Systemd is the default init system. The default dependencies should
> > > reflect that.
> > 
> > It has already been explained that it being the default makes the
> > order switching irrelevant for what you recommend. If people are using
> > the default init, the dependency will already be satisfied and life
> > will not be disrupted. The same thing should happen if people are
> > using a different init: that decision should be maintained unless they
> > manually uninstall the package that satisfies the init package's
> > dependency.
> 
> Most Debian systems aren't using sysvinit by active choice, but because
> it was the default when they installed their machines, so this argument
> doesn't really make sense.

Does that mean that we can happily break their hand made configurations for 
their was-default current init system?

If our priorities are free software and _our users_ of course not.

Regards

Noel
er Envite


signature.asc
Description: This is a digitally signed message part.

Re: systemd, again (Re: Cinnamon environment now available in testing)

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/08/2014 at 02:05 AM, Helmut Grohne wrote:

> On Sun, Sep 07, 2014 at 11:12:01PM +1200, Chris Bannister wrote:
> 
>> Surely, it should be an OPT-IN choice, not an OPT-OUT one? I'm 
>> talking upgrades here, not new installs.
> 
> I have no clue why we are continuing to discuss this. The ctte 
> resolution says that "the default init system for Linux 
> architectures in jessie should be systemd". There is no extra 
> provision "on new installs" in the resolution.

I suspect that the reason we're continuing to discuss this is that
different people have different individually-reasonable understandings
of what "default" means in this context. Was the question of the meaning
of that term in this context raised / addressed in the TC discussion?

I'm pretty sure at least a large fraction of the remaining disagreements
I've seen under discussion lie in conflicting understandings of that
meaning, and it looked as if the current discussion might be getting
closer to clarifying people's conflicting understandings - which can
only help, even if no official Debian position as to the meaning is
decided on.

- -- 
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJUDZhNAAoJEASpNY00KDJrkpsP/j9XKIHooZRycTJs/a+UBOdB
DYIPnbYy48Jxaz4X/txbxdTLuf7pFpg97w8eH6g54934C4OzJI+ikFMk8zydCRQW
d8WFI3b4OB1zrYAnVfPV8shWbacqpzYkFC8xjylsvEvxQo1VvnKCGsKv8ymfxBdW
D/YkBPCEbrbjOMZ57w06mqAX06K6z+E0XsyZqoFiUPnk2JepLANswKogRJzoKCqa
MUT+vUHdK/SpmtQQe6r0LoHA8oWxpnb8gKX/svzmirUkAVjr5oDCydq8vQGePNii
RF9zNNhDmwwKur7CB8IjDR20/AkclTzW2lSyZn3B+vcWVFZP+KGtQpJguhGjsvlH
sER2e073+arsGIgqNMC8JHay+e6AWP0NjYI4D8ZtWPUIS0FWk70xiz3UhI1JFrBz
7Co2OeGeNj96CxeyNgY0DueaTm4LTLZ40XllWrgoGeArz4Y4Sv43ukXUJpYTXf4r
a0vXnJs4ew5rc4kXmha3RNEzUC+TlGlmUxb5A5Vug4wpipH6y0c0YotDHsqQTS5h
EolDFm1s7WmqPvqXZwrTxKxWDGY9B8Di31So4G+7QMaNej6joMaWP3GU1Hi6T1X3
tguQ6K+sA3L2tbIyQpGqdUvVFuMR9Nb4UjfmDchLp3VVvHYNeYhVpheCertS1yqU
bS1qIf8EHk3anab747tw
=UMhm
-END PGP SIGNATURE-


-- 
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/540d984d.1030...@fastmail.fm

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Jakub Wilk]

* Josselin Mouette , 2014-09-08, 10:58:
Excuse me? Are you trying to use the fact that you and your stupid 
friends are trolling about systemd all day long in order to justify 
your own rants?


And I thought you couldn’t get any lower. You have a very good shovel.


OTOH, a hydraulic excavator must have been involved in writing your 
mail.


Can we now all go back to the ground level? (Or higher?!)

--
Jakub Wilk


--
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/20140908101219.ga...@jwilk.net

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Josselin Mouette]

Adam Borowski wrote:
> Noel Torres  writes:
> > So, in your POV, forcing millions of sysadmins out there to take 
extra pain to 
> > keep their systems running as they expect is the way to go?
> 
> I think it's fair to expect the few hundred people[1] that want to 
run a
> non-default init system to do so, yes.
> 
>   [1] I can also make up numbers :)

Ok, so let's quantify the view of sysadmins somehow.  This can actually
be done in a meaningful way: let's count posts on places where
technically-minded folks gather.  There's plenty of minor blogs that are
biased, but let's choose big sites where we can have a reasonable chance
of being unbiased.  I chose Slashdot and it's fork, SoylentNews.

Excuse me? Are you trying to use the fact that you and your stupid
friends are trolling about systemd all day long in order to justify your
own rants? 

And I thought you couldn’t get any lower. You have a very good shovel.

-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-



-- 
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/1410166714.8969.384.camel@dsp0698014

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Helmut Grohne]

On Sun, Sep 07, 2014 at 11:12:01PM +1200, Chris Bannister wrote:
> Surely, it should be an OPT-IN choice, not an OPT-OUT one? I'm talking
> upgrades here, not new installs.

I have no clue why we are continuing to discuss this. The ctte
resolution says that "the default init system for Linux architectures in
jessie should be systemd". There is no extra provision "on new installs"
in the resolution. If you want OPT-IN, your options are:

 * Ask the ctte to further clarify their position.
 * Raise a GR.

Your options do not include:

 * Further pester debian-devel with this matter.

That said, it certainly makes sense to document how to opt out of
systemd in the release notes. I guess you just volunteered.

Thanks in advance

Helmut


-- 
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/20140908060511.ga27...@alf.mars

Re: Cinnamon environment now available in testing

[Cameron Norman]

El dom, 7 de sep 2014 a las 3:45 , David Weinehall  
escribió:

On Fri, Sep 05, 2014 at 12:37:12PM -0700, Cameron Norman wrote:
 On Fri, Sep 5, 2014 at 1:57 AM, Josselin Mouette  
wrote:

 > Noel Torres wrote:
 >> So we are clearly failing to follow the least surprise (for the 
user) path.

 >>
 >> Should not logind depend on systemd-shim | systemd-sysv instead?
 >
 > No. Systemd is the default init system. The default dependencies 
should

 > reflect that.
 
 It has already been explained that it being the default makes the
 order switching irrelevant for what you recommend. If people are 
using

 the default init, the dependency will already be satisfied and life
 will not be disrupted. The same thing should happen if people are
 using a different init: that decision should be maintained unless 
they

 manually uninstall the package that satisfies the init package's
 dependency.


Most Debian systems aren't using sysvinit by active choice, but 
because
it was the default when they installed their machines, so this 
argument

doesn't really make sense.


But some are, and this completely leaves them out in the cold. One 
option is to put a "heads up" in systemd-sysv, or some other type of 
glue so that on an upgrade, people know what is happening to their 
systems.


Best regards,
--
Cameron

Re: Cinnamon environment now available in testing

[David Weinehall]

On Fri, Sep 05, 2014 at 12:37:12PM -0700, Cameron Norman wrote:
> On Fri, Sep 5, 2014 at 1:57 AM, Josselin Mouette  wrote:
> > Noel Torres wrote:
> >> So we are clearly failing to follow the least surprise (for the user) path.
> >>
> >> Should not logind depend on systemd-shim | systemd-sysv instead?
> >
> > No. Systemd is the default init system. The default dependencies should
> > reflect that.
> 
> It has already been explained that it being the default makes the
> order switching irrelevant for what you recommend. If people are using
> the default init, the dependency will already be satisfied and life
> will not be disrupted. The same thing should happen if people are
> using a different init: that decision should be maintained unless they
> manually uninstall the package that satisfies the init package's
> dependency.

Most Debian systems aren't using sysvinit by active choice, but because
it was the default when they installed their machines, so this argument
doesn't really make sense.


Kind regards, David Weinehall
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20140907224512.gc3...@hirohito.acc.umu.se

Re: Cinnamon environment now available in testing

[Christoph Anton Mitterer]

Hey.

On Sat, 2014-09-06 at 14:08 +0200, Michael Biebl wrote: 
> Steve, as long as bugs like [1] are not fixed in systemd-shim, I'm not
> going to make it the first alternative. Installing a half-broken logind
> whould be a disservice to our users.
Kinda strange to use *that* as an argument, while you guys to basically
the very same with NetworkManager for a long time now.

It's more any more forced upon users while at the same time, it's
basically broken for most but a very little subset of lowest-end-user
scenarios.
At the same time, both upstream and the maintainers, state that they do
not intend to make NM working/integrate with the native network managing
tools, or other such toolsets.


So apart from the fact that I'm mostly in favour of systemd, it's kinda
strange to read the argument we should not "install a half-broken [...]
whould be a disservice to our users."


o.O


Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Marc Haber]

On Sun, 07 Sep 2014 15:30:11 +0200, Tollef Fog Heen 
wrote:
>You make the assumption that there's not been an tries to resolve this,
>which is wrong.  As for security, well, I have a keyscript that unlocks
>my boot drive just fine, but handled through initramfs, not systemd.

Those tries are invisible in the bug report, which is bad.

To investigate, I need time to set up a breakable reference system. I
broke an important productive system by an unwanted "upgrade" to
systemd once, that's not going to happen to me again.

Greetings
Marc
-- 
-- !! 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


--
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/e1xqell-0001dx...@swivel.zugschlus.de

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Matthias Urlichs]

Hi,

Chris Bannister:
> > If technically feasible, that would be a far better safety net (just tell
> > people to boot with init=/sbin/sysvinit if they run into a problem) than
> > an "oh dear, it's so dangerous that we don't even install it by default"
> > message. :-/
> 
> Surely, it should be an OPT-IN choice, not an OPT-OUT one? I'm talking
> upgrades here, not new installs.
> 
I am talking "if we decide to use a configurable symlink, then
surely systemd will have the highest priority". [*]

Yes, that does mean that, if you do not do anything else, your system will
boot with systemd. Which IMHO is as it should be.

Quite frankly: If you're savvy enough to do something to your init setup
that is no longer supported, and at the same time stupid enough to upgrade
to Jessie without reading the release notes _and_ ignore systemd-sysv's
debconf notice (which doesn't exist yet, but should probably be added),
then that's your own damn fault.

[*] /etc/alternatives isn't really suitable for this, because you could not
boot with an empty /etc directory. systemd wants to be able to do that
("factory reset"). But there are other possibilities.

-- 
-- Matthias Urlichs


-- 
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/20140907151102.go21...@smurf.noris.de

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Holger Levsen]

Hi,

On Samstag, 6. September 2014, Matthias Urlichs wrote:
> No. I expect them all to continue running just peachy fine and seamlessly.
> I also expect the Jessie upgrade to switch to systemd. Because, frankly and
> strictly IMHO, doing anything else makes no sense whatsoever.
> 
> On the other hand, I *do* expect anybody who does NOT want to switch to
> systemd to already know before upgrading that they'll need to do somethink
> non-standard if they really want to stay with sysVinit / switch to
> [another_init] instead, simply because they already know that the default
> upgrade will switch.

FWIW, I fully agree. 

This is how I expect upgrades to Jessie and new installs will be handled. I 
also think installing with legacy or less widely used initsystems should be 
well hidden (and probably explained in the manual).

I guess a good opportunity for contributors not captable of extending d-i to 
do this, is to contribute patches to the manual.


cheers,
Holger




signature.asc
Description: This is a digitally signed message part.

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Tollef Fog Heen]

]] Marc Haber 

> On Sat, 6 Sep 2014 15:56:23 +0200, Matthias Urlichs
>  wrote:
> >Marc Haber:
> >> On Fri, 05 Sep 2014 15:12:50 +0200, Svante Signell
> >>  wrote:
> >> >On Fri, 2014-09-05 at 14:20 +0200, Matthias Urlichs wrote:
> >> >> Thus, unless the user explicitly tells the apt{-get,itude} subsystem not
> >> >> to switch to systemd (by whatever means, the details of which I 
> >> >> personally
> >> >> am not at all interested in), a dist-upgrade should do so.
> >> >
> >> >How? All efforts so far and bugs reported are being brought down
> >> >actively.
> >> 
> >> #618862, dating back to 2011 and with no Debian maintainer reaction in
> >> months?
> >> 
> >This bug's latest entry asks the original reporter whether the bug still
> >applies.
> 
> The long, anonymous elaborate does not address the actual issue. And,
> it's clear that - should the anonymous poster be correct - keyscript
> is only supported for the root file system, not for any other fsses
> that might get mounted later.

It works for anything that's mounted from the initramfs, not just the
root file system, in addition to anything mounted by hand later, but
otherwise that's correct.

> >The systemd transition is not simple. I do not think it's reasonable to
> >expect the Debian maintainer to be able to reproduce every problem, so what
> >else would you have them do about this bug?
> 
> I would expect at least a try to keep something supported that has
> been supported in Debian für years. This is a serious regression that
> makes systems unbootable and up to now the only fix seems to be to
> reduce security by resorting to keys typed in at boot time.

You make the assumption that there's not been an tries to resolve this,
which is wrong.  As for security, well, I have a keyscript that unlocks
my boot drive just fine, but handled through initramfs, not systemd.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/m2bnqr36e4@rahvafeir.err.no

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Sune Vuorela]

On 2014-09-07, Sune Vuorela  wrote:
> I had my systems painfully and transparantly upgraded to systemd. And
> I'm happy it happens. Please keep it this way.

I apparantly like pain. or maybe s/ful/less/ is the appropriate reading.

/Sune


-- 
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/luhkds$qpi$1...@ger.gmane.org

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Sune Vuorela]

On 2014-09-07, Chris Bannister  wrote:
> Surely, it should be an OPT-IN choice, not an OPT-OUT one? I'm talking
> upgrades here, not new installs.

I had my systems painfully and transparantly upgraded to systemd. And
I'm happy it happens. Please keep it this way.

I do want my systems to look the same, no matter if it is my workstation
installed-as-woody or my laptop reinstalled yesterday.

/Sune


-- 
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/luhiqv$8t6$1...@ger.gmane.org

Re: Cinnamon environment now available in testing

[Michael Biebl]

Am 07.09.2014 14:08, schrieb Thorsten Glaser:
> On Sat, 6 Sep 2014, Michael Biebl wrote:
> 
>> Steve, as long as bugs like [1] are not fixed in systemd-shim, I'm not
>> going to make it the first alternative. Installing a half-broken logind
>> whould be a disservice to our users.
> 
> Uhm, did you read this subthread at all?

I did, but apparently you didn't understand what I said.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Cinnamon environment now available in testing

[Thorsten Glaser]

On Sat, 6 Sep 2014, Michael Biebl wrote:

> Steve, as long as bugs like [1] are not fixed in systemd-shim, I'm not
> going to make it the first alternative. Installing a half-broken logind
> whould be a disservice to our users.

Uhm, did you read this subthread at all?

Let me try to summarise:

At best, switching the order would be no change in the systemd
scenario, but improve the situation for users of other init
systems.

At worst, switching the order would install a package that is
a no-op in the systemd scenario, but improve the situation for
users of other init systems.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)


--
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/alpine.deb.2.11.1409071406500.4...@tglase.lan.tarent.de

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Chris Bannister]

On Sun, Sep 07, 2014 at 12:18:08PM +0200, Matthias Urlichs wrote:
> Hi,
> 
> Zack Weinberg:
> > I think this strategy is positively _necessary_ in order to ensure
> > that systems currently running Wheezy can safely be upgraded to
> > Jessie.  There are simply too many wacky configurations out there; it
> 
> If we do decide that a default switch is unsafe for too many systems, then
> I wouldn't have a problem with, for instance, adding a debconf question to
> systemd-sysv's preinst which tells people what to do if they don't want
> systemd for whatever reason.
> 
> > [ symlink and co-installability ]
> 
> If technically feasible, that would be a far better safety net (just tell
> people to boot with init=/sbin/sysvinit if they run into a problem) than
> an "oh dear, it's so dangerous that we don't even install it by default"
> message. :-/

Surely, it should be an OPT-IN choice, not an OPT-OUT one? I'm talking
upgrades here, not new installs.

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
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/20140907111201.GA11840@tal

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Matthias Urlichs]

Hi,

Zack Weinberg:
> I think this strategy is positively _necessary_ in order to ensure
> that systems currently running Wheezy can safely be upgraded to
> Jessie.  There are simply too many wacky configurations out there; it

If we do decide that a default switch is unsafe for too many systems, then
I wouldn't have a problem with, for instance, adding a debconf question to
systemd-sysv's preinst which tells people what to do if they don't want
systemd for whatever reason.

> [ symlink and co-installability ]

If technically feasible, that would be a far better safety net (just tell
people to boot with init=/sbin/sysvinit if they run into a problem) than
an "oh dear, it's so dangerous that we don't even install it by default"
message. :-/

-- 
-- Matthias Urlichs


-- 
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/20140907101808.gn21...@smurf.noris.de

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Marc Haber]

On Sat, 6 Sep 2014 15:56:23 +0200, Matthias Urlichs
 wrote:
>Marc Haber:
>> On Fri, 05 Sep 2014 15:12:50 +0200, Svante Signell
>>  wrote:
>> >On Fri, 2014-09-05 at 14:20 +0200, Matthias Urlichs wrote:
>> >> Thus, unless the user explicitly tells the apt{-get,itude} subsystem not
>> >> to switch to systemd (by whatever means, the details of which I personally
>> >> am not at all interested in), a dist-upgrade should do so.
>> >
>> >How? All efforts so far and bugs reported are being brought down
>> >actively.
>> 
>> #618862, dating back to 2011 and with no Debian maintainer reaction in
>> months?
>> 
>This bug's latest entry asks the original reporter whether the bug still
>applies.

The long, anonymous elaborate does not address the actual issue. And,
it's clear that - should the anonymous poster be correct - keyscript
is only supported for the root file system, not for any other fsses
that might get mounted later.

>The systemd transition is not simple. I do not think it's reasonable to
>expect the Debian maintainer to be able to reproduce every problem, so what
>else would you have them do about this bug?

I would expect at least a try to keep something supported that has
been supported in Debian für years. This is a serious regression that
makes systems unbootable and up to now the only fix seems to be to
reduce security by resorting to keys typed in at boot time.

Greetings
Marc
-- 
-- !! 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


--
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/e1xqyd7-js...@swivel.zugschlus.de

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Andreas Metzler]

Zack Weinberg  wrote:
> Matthias Urlichs wrote:

>> I also expect the Jessie upgrade to switch to systemd. Because,
>> frankly and strictly IMHO, doing anything else makes no sense
>> whatsoever.

> This is exactly the thing I don't agree with.

> I think _new installs_ of Jessie should use systemd as init (by
> default, anyway), but _upgrades_ from Wheezy or prior should continue
> to use whatever it is they were using before the upgrade, until the
> administrator takes an additional positive action to convert to
> something else.  And I also think that "additional positive action"
[...]

Hello,

I think that is terrible idea, because it makes us release a system
that is lot less tested than it should be. If only fresh installs were
using our default init system this part would only get very limited
testing pre-freeze. The number of systems running testing or even
unstable is going to be a lot higher than the number of people doing
fresh installs from a d-i alpha or beta version.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
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/p59tdb-3i4@argenau.downhill.at.eu.org

Re: There should not be dependencies on systemd (Was: Cinnamon environment now available in testing)

[James McCoy]

On Sun, Sep 07, 2014 at 02:20:33AM +0200, Guillem Jover wrote:
> On Sun, 2014-09-07 at 00:05:59 +0200, Marco d'Itri wrote:
> > On Sep 06, Noel Torres  wrote:
> > > It is just wrong to have dependencies on the init system.
> > > If you need dbus, you should Depend on dbus, and systemd should 
> > > Provides dbus.
> 
> > This is why most of these dependencies are on libpam-systemd, which does 
> > not depend on systemd.
> 
> That's incorrect:

No, it isn't.  It was just poorly worded.

> $ apt-cache show libpam-systemd | egrep '^(Version|Depends):'
> Version: 214-1
> Depends: libc6 (>= 2.17), libcap2 (>= 2.10), libpam0g (>= 0.99.7.1),
>   systemd (= 214-1), libpam-runtime (>= 1.0.1-6), dbus,
>   systemd-sysv | systemd-shim (>= 6-4)

While libpam-systemd does Depend on the systemd binary package, that
package does not enforce systemd as the init system.  The relevant
relationship there is the ORed “systemd-sysv | systemd-shim (>= 6-4)”.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


-- 
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/20140907011959.gf26...@freya.jamessan.com

Re: There should not be dependencies on systemd (Was: Cinnamon environment now available in testing)

[Marco d'Itri]

On Sep 07, Guillem Jover  wrote:

> > This is why most of these dependencies are on libpam-systemd, which does 
> > not depend on systemd.
> That's incorrect:
What I meant was "does not depend on systemd being PID 1".
Are you happy now?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: There should not be dependencies on systemd (Was: Cinnamon environment now available in testing)

[Guillem Jover]

On Sun, 2014-09-07 at 00:05:59 +0200, Marco d'Itri wrote:
> On Sep 06, Noel Torres  wrote:
> > It is just wrong to have dependencies on the init system.
> > If you need dbus, you should Depend on dbus, and systemd should 
> > Provides dbus.

> This is why most of these dependencies are on libpam-systemd, which does 
> not depend on systemd.

That's incorrect:

$ apt-cache show libpam-systemd | egrep '^(Version|Depends):'
Version: 214-1
Depends: libc6 (>= 2.17), libcap2 (>= 2.10), libpam0g (>= 0.99.7.1),
  systemd (= 214-1), libpam-runtime (>= 1.0.1-6), dbus,
  systemd-sysv | systemd-shim (>= 6-4)
Version: 208-8
Depends: libc6 (>= 2.14), libcap2 (>= 1:2.10), libdbus-1-3 (>= 1.0.2),
  libpam0g (>= 0.99.7.1), systemd (= 208-8), libpam-runtime (>= 1.0.1-6),
  dbus, systemd-sysv | systemd-shim (>= 6-4)

> As usual, people complain about perceived systemd problems that have 
> already been solved.

…

Regards,
Guillem


-- 
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/20140907002033.ga8...@gaara.hadrons.org

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Marco d'Itri]

On Sep 06, Sven Joachim  wrote:

> Here's what I get when replacing sysvinit-core with systemd-sysv in my
> pbuilder chroot:
To be fair, most of these packages (adduser, kmod, udev and their 
dependencies, for a start) would be installed anyway on a normal system 
which is not a minimal chroot.
If you ignore these then you are left with pretty much only the dmsetup 
and cryptsetup-related packages, which are quite common as well.

A good but slightly dated analisys is available at 
https://people.debian.org/~stapelberg/docs/systemd-dependencies.html .

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: There should not be dependencies on systemd (Was: Cinnamon environment now available in testing)

[Marco d'Itri]

On Sep 06, Noel Torres  wrote:

> It is just wrong to have dependencies on the init system.
> If you need dbus, you should Depend on dbus, and systemd should 
> Provides dbus.
This is why most of these dependencies are on libpam-systemd, which does 
not depend on systemd.

As usual, people complain about perceived systemd problems that have 
already been solved.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Russ Allbery]

Sven Joachim  writes:
> On 2014-09-05 23:50 +0200, Russ Allbery wrote:

>> That seems much higher than I believe is the case.  Wasn't there a
>> detailed analysis of this posted a while back?  My vague recollection
>> was a number more on the order of a quarter of that, and with most of
>> those being quite small (such as libsystemd-daemon0, which counts as a
>> package but which has an installed size of 72KB).

> Here's what I get when replacing sysvinit-core with systemd-sysv in my
> pbuilder chroot:

Thanks, Sven.  Yeah, that's more on the order of what I expected, and is
rather less than 100 packages.

> ,
> | The following NEW packages will be installed:
> |   acl{a} (D: systemd)  adduser{a} (D: systemd)  dmsetup{a} (D: 
> libdevmapper1.02.1)  
> |   libcap2-bin{a} (D: systemd)  libcryptsetup4{a} (D: systemd)  
> |   libdbus-1-3{a} (P: systemd, D: systemd)  
> |   libdevmapper1.02.1{a} (D: dmsetup, D: libcryptsetup4)  
> |   libgcrypt11{a} (P: systemd, D: libsystemd-journal0)  
> |   libgcrypt20{a} (D: libcryptsetup4)  
> |   libgpg-error0{a} (D: libcryptsetup4, D: libgcrypt11, D: libgcrypt20)  
> |   libkmod2{a} (D: systemd, D: udev)  libprocps3{a} (D: procps)  
> |   libsystemd-daemon0{a} (P: systemd)  libsystemd-journal0{a} (D: systemd)  
> |   libsystemd-login0{a} (D: systemd)  
> |   libudev1{a} (D: libdevmapper1.02.1, D: systemd, D: udev)  
> |   libwrap0{a} (D: systemd)  procps{a} (D: udev)  
> |   systemd{a} (P: systemd-sysv, D: systemd-sysv)  systemd-sysv  
> |   udev{a} (D: systemd)  
> | The following packages will be REMOVED:
> |   sysvinit-core  
> | The following packages are RECOMMENDED but will NOT be installed:
> |   dbus (R: libdbus-1-3)  libpam-cap (R: libcap2-bin)  libpam-systemd (R: 
> systemd)  
> |   psmisc (R: initscripts, R: procps)  tcpd (R: libwrap0)  
> | 0 packages upgraded, 21 newly installed, 1 to remove and 0 not upgraded.
> | Need to get 0 B/4436 kB of archives. After unpacking 18.1 MB will be used.
> `

Note also that a few of those things (udev, adduser, and
libdevmapper1.02.1 for example) are likely to be on any non-chroot system
already since they're either dependencies of other things (such as grub
for libdevmapper1.02.1) or are already in use regardless of the init
system (udev).  So for the case of a small embedded system that's
nonetheless running the full kernel + bootloader stack, I suspect the
delta is even smaller.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/8761h066vq@hope.eyrie.org