Discussion:
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
(too old to reply)
Svante Signell
2014-12-02 17:20:03 UTC
Permalink
Package: release-notes
Severity: Important

Hello,

As promised on debian-devel attached is a first proposal for an update
of the release notes. There are two small issues with the patch:
- The text is edited without seeing the markup result. How to do that?
- The second part about preseeding will be tested tonight, and an
updated patch will be submitted if any changes are needed.

Thanks!
Niels Thykier
2014-12-02 21:20:01 UTC
Permalink
Post by Svante Signell
Package: release-notes
Severity: Important
Hello,
As promised on debian-devel attached is a first proposal for an update
- The text is edited without seeing the markup result. How to do that?
- The second part about preseeding will be tested tonight, and an
updated patch will be submitted if any changes are needed.
Thanks!
Hi,

Thanks for taking the time to write a patch for the release notes.

I have two remarks:

* It is not clear to me that this is a valid patch against the original
source of the release notes (SVN)[1]. I can certainly extract the
relevant parts and apply it manually, but this is inefficient use of
our time (yours and mine) in the long run.

* The second "hunk" of the patch seems better suited for the
installation-guide. The release notes concerns itself with upgrades
and does not cover the debian-installer.


The original source of the release notes is at [2]. There is a git
clone maintained by Julien at [3] if you prefer git over SVN.

To build the release notes (for a single language and architecture), you
run:

make html LINGUA="en" architecture=amd64

Which would build the English HTML version for amd64. The generated
output will be in en/release-notes.amd64.html/index.en.html.
NB: Some parts of the build system assumes you have a subversion
checkout. The above command does not, but if you simply run "make"
without any arguments you will trigger some of them.

~Niels

[1] I would be expecting you to modify a file called "en/issues.dbk"...
and I am not sure what the "numbers" at the beginning of each line is
doing in an XML document, but...

[2] https://anonscm.debian.org/viewvc/ddp/manuals/trunk/release-notes/

[3] https://anonscm.debian.org/cgit/users/jcristau/release-notes.git/
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Svante Signell
2014-12-02 22:10:02 UTC
Permalink
Post by Niels Thykier
Post by Svante Signell
Package: release-notes
Severity: Important
Hello,
As promised on debian-devel attached is a first proposal for an update
- The text is edited without seeing the markup result. How to do that?
- The second part about preseeding will be tested tonight, and an
updated patch will be submitted if any changes are needed.
Thanks!
Hi,
Thanks for taking the time to write a patch for the release notes.
* It is not clear to me that this is a valid patch against the original
source of the release notes (SVN)[1]. I can certainly extract the
relevant parts and apply it manually, but this is inefficient use of
our time (yours and mine) in the long run.
See below.
Post by Niels Thykier
* The second "hunk" of the patch seems better suited for the
installation-guide. The release notes concerns itself with upgrades
and does not cover the debian-installer.
Somebody was complaining that changing the installation-guide was a lot
of work, e.g. translations work, and did not want the changes to be made
there https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765803#40
I don't mind getting the second part included there instead.
Post by Niels Thykier
The original source of the release notes is at [2]. There is a git
clone maintained by Julien at [3] if you prefer git over SVN.
To build the release notes (for a single language and architecture), you
make html LINGUA="en" architecture=amd64
Which would build the English HTML version for amd64. The generated
output will be in en/release-notes.amd64.html/index.en.html.
NB: Some parts of the build system assumes you have a subversion
checkout. The above command does not, but if you simply run "make"
without any arguments you will trigger some of them.
I will fix that tomorrow, thanks!
Post by Niels Thykier
~Niels
[1] I would be expecting you to modify a file called "en/issues.dbk"...
and I am not sure what the "numbers" at the beginning of each line is
doing in an XML document, but...
I did cut and paste from the web page in iceweasel:

https://anonscm.debian.org/viewvc/ddp/manuals/trunk/release-notes/en/issues.dbk?view=markup&pathrev=10511

That's where the line numbers came from. I should have downloaded the
page and edited that one instead.
Post by Niels Thykier
[2] https://anonscm.debian.org/viewvc/ddp/manuals/trunk/release-notes/
[3] https://anonscm.debian.org/cgit/users/jcristau/release-notes.git/
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Javier Fernández-Sanguino Peña
2014-12-02 23:10:02 UTC
Permalink
Post by Svante Signell
Post by Niels Thykier
* The second "hunk" of the patch seems better suited for the
installation-guide. The release notes concerns itself with upgrades
and does not cover the debian-installer.
Somebody was complaining that changing the installation-guide was a lot
of work, e.g. translations work, and did not want the changes to be made
there https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765803#40
I don't mind getting the second part included there instead.
Translators (and I'm one of them) will have to update the installation-guide
before the release.

I think it's better to have the document where it should be and also agree
that the Release Notes is not the place for that chunk.

Best regards

Javier
Svante Signell
2014-12-03 11:00:02 UTC
Permalink
Post by Niels Thykier
Post by Svante Signell
Package: release-notes
Severity: Important
[1] I would be expecting you to modify a file called "en/issues.dbk"...
and I am not sure what the "numbers" at the beginning of each line is
doing in an XML document, but...
Attached is a svn diff for the release-notes. Comments are welcomed.

Regarding the Installation guide for the second hunk, where to get that
stuff?

Thanks!
Niels Thykier
2014-12-03 21:10:02 UTC
Permalink
Post by Svante Signell
[...]
Hi,
Post by Svante Signell
Attached is a svn diff for the release-notes. Comments are welcomed.
Thanks, find my remarks interleaved in the patch.
Post by Svante Signell
Regarding the Installation guide for the second hunk, where to get that
stuff?
I believe it is a real package (compared to the release-notes, which is
"just" a pseudo-package).
Post by Svante Signell
Thanks!
en_issues.dbk.patch
Index: en/issues.dbk
===================================================================
--- en/issues.dbk (revision 10513)
+++ en/issues.dbk (working copy)
@@ -183,7 +183,7 @@
role="package">sysvinit-core</systemitem> or <systemitem
role="package">upstart</systemitem>, it is recommended to setup
APT pinning prior to the upgrade. As an example, to prevent
- <systemitem role="package">systemd</systemitem> from being
+ <systemitem role="package">systemd-sysv</systemitem> from being
Indeed, the package name is systemd-sysv.
Though perhaps we should change it to "systemd" without marking it as
a package. I presume that the user/admin is less interested in the
actual package name and more in the name of the init system.
Post by Svante Signell
installed during the upgrade, you can create a file called
<filename>/etc/apt/preferences.d/local-pin-init</filename> with
@@ -193,12 +193,16 @@
Pin: release o=Debian
Pin-Priority: -1
</screen>
- <caution>
- <para>
- Be advised that some packages may have degraded behaviour or
- may be lacking features under a non-default init system.
- </para>
- </caution>
I am not too happy with pushing the <caution> down. To be honest, I
have been considering to push it "up".
Post by Svante Signell
+ <note>
I am not entirely convinced this should be a "<note>" rather than a
"<para>".
Post by Svante Signell
+ It is also good to install
It is also a good idea to install ...?
Post by Svante Signell
+ <systemitem role="package"> sysvinit-core, sysvint and sysvinit-utils
+ </systemitem> as the first packages when upgrading. In case
+ you want an <emphasis>as-systemd-free-as-possible</emphasis>
Not sure why the emphasis here. To be honest, the sentence strikes me
as a bit odd (and possibly a bit long). Maybe just add it to the list
above or simply just:

"""If you have a desktop environment installed, it is also recommended
to install systemd-shim to assist apt or/and aptitude with the upgrade
path."""
Post by Svante Signell
+ desktop environment, it is also recommended to install <systemitem
+ role="package">systemd-shim</systemitem> in order to
+ help apt and aptitude to avoid installing systemd-sysv and
+ other *systemd* components, unintentionally.
^^^^^^^^^

Why the "*X*"? We got <emphasis> if you want to highlight. Then again,
see my previous remark about the entire sentence.
Post by Svante Signell
[...]
Thanks for considering,
~Niels
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Svante Signell
2014-12-04 11:10:02 UTC
Permalink
Post by Niels Thykier
Post by Svante Signell
[...]
Index: en/issues.dbk
===================================================================
--- en/issues.dbk (revision 10513)
+++ en/issues.dbk (working copy)
@@ -183,7 +183,7 @@
role="package">sysvinit-core</systemitem> or <systemitem
role="package">upstart</systemitem>, it is recommended to setup
APT pinning prior to the upgrade. As an example, to prevent
- <systemitem role="package">systemd</systemitem> from being
+ <systemitem role="package">systemd-sysv</systemitem> from being
Indeed, the package name is systemd-sysv.
Though perhaps we should change it to "systemd" without marking it as
a package. I presume that the user/admin is less interested in the
actual package name and more in the name of the init system.
Problem is: Does the pinning work if it is on systemd instead of
systemd-sysv? The the pin would be about any systemd component?
Post by Niels Thykier
Post by Svante Signell
installed during the upgrade, you can create a file called
<filename>/etc/apt/preferences.d/local-pin-init</filename> with
@@ -193,12 +193,16 @@
Pin: release o=Debian
Pin-Priority: -1
</screen>
- <caution>
- <para>
- Be advised that some packages may have degraded behaviour or
- may be lacking features under a non-default init system.
- </para>
- </caution>
I am not too happy with pushing the <caution> down. To be honest, I
have been considering to push it "up".
Pushed up, as you wish.
Post by Niels Thykier
Post by Svante Signell
+ <note>
I am not entirely convinced this should be a "<note>" rather than a
"<para>".
Fixed by using <itemizedlist> instead!
Post by Niels Thykier
Post by Svante Signell
+ It is also good to install
It is also a good idea to install ...?
Fixed!
Post by Niels Thykier
Post by Svante Signell
+ <systemitem role="package"> sysvinit-core, sysvint and sysvinit-utils
+ </systemitem> as the first packages when upgrading. In case
+ you want an <emphasis>as-systemd-free-as-possible</emphasis>
Not sure why the emphasis here. To be honest, the sentence strikes me
as a bit odd (and possibly a bit long). Maybe just add it to the list
"""If you have a desktop environment installed, it is also recommended
to install systemd-shim to assist apt or/and aptitude with the upgrade
path."""
Rewritten!
Post by Niels Thykier
Post by Svante Signell
+ desktop environment, it is also recommended to install <systemitem
+ role="package">systemd-shim</systemitem> in order to
+ help apt and aptitude to avoid installing systemd-sysv and
+ other *systemd* components, unintentionally.
^^^^^^^^^
Fixed!
Post by Niels Thykier
Why the "*X*"? We got <emphasis> if you want to highlight. Then again,
see my previous remark about the entire sentence.
New patch attached. Better now?

Note the comment about the CTTE decision today (hopefully) about default
init system on upgrades!
Andrei POPESCU
2014-12-06 14:00:02 UTC
Permalink
Post by Svante Signell
Post by Niels Thykier
Indeed, the package name is systemd-sysv.
Though perhaps we should change it to "systemd" without marking it as
a package. I presume that the user/admin is less interested in the
actual package name and more in the name of the init system.
Problem is: Does the pinning work if it is on systemd instead of
systemd-sysv? The the pin would be about any systemd component?
systemd-sysv Depends: systemd, so yes, it should work. However, since
libpam-systemd (and AFAIU systemd-shim might as well) also depends on it
this would effectively prevent one from installing anything that
Depends: libpam-systemd

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt
Joost van Baal-Ilić
2014-12-14 11:00:02 UTC
Permalink
Hi Svante,

Care to update the patch now that the CTTE-decision has been taken? I can
apply the patch today.
Post by Svante Signell
Post by Niels Thykier
Post by Svante Signell
[...]
Index: en/issues.dbk
===================================================================
--- en/issues.dbk (revision 10513)
+++ en/issues.dbk (working copy)
@@ -183,7 +183,7 @@
role="package">sysvinit-core</systemitem> or <systemitem
role="package">upstart</systemitem>, it is recommended to setup
APT pinning prior to the upgrade. As an example, to prevent
- <systemitem role="package">systemd</systemitem> from being
+ <systemitem role="package">systemd-sysv</systemitem> from being
Indeed, the package name is systemd-sysv.
Though perhaps we should change it to "systemd" without marking it as
a package. I presume that the user/admin is less interested in the
actual package name and more in the name of the init system.
Problem is: Does the pinning work if it is on systemd instead of
systemd-sysv? The the pin would be about any systemd component?
Furthermore, "systemd" could refer to either the init-system or the complete
systemd suite. In order to be sure no confusion arrises, I'd stick with
<systemitem role="package">systemd-sysv</systemitem>.

<snip>
Post by Svante Signell
Post by Niels Thykier
Why the "*X*"? We got <emphasis> if you want to highlight. Then again,
see my previous remark about the entire sentence.
New patch attached. Better now?
Yes, thanks.
Post by Svante Signell
Note the comment about the CTTE decision today (hopefully) about default
init system on upgrades!
Index: en/issues.dbk
===================================================================
--- en/issues.dbk (revision 10513)
+++ en/issues.dbk (working copy)
@@ -178,12 +178,16 @@
<para>
Jessie ships with <systemitem
role="package">systemd-sysv</systemitem> as
- <emphasis>default</emphasis> init system. If you have a
- preference for another init such as <systemitem
+ <emphasis>default</emphasis> init system.
+ This package is installed automatically on upgrades
+ <emphasis>(pending the CTTE decision today)</emphasis>.
+ </para>
+ <para>
+ If you have a preference for another init such as <systemitem
<snip>


Thanks for your work! Bye,

Joost
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Svante Signell
2014-12-15 15:10:04 UTC
Permalink
Post by Joost van Baal-Ilić
Hi Svante,
Care to update the patch now that the CTTE-decision has been taken? I can
apply the patch today.
Thanks for your work! Bye,
Attached is an updated patch, adding some information about apt-get
upgrade and apt-get dist-upgrade, as well as the grub new entry. I'll
create a Wheezy image and try out the examples in the patch (if/when
time permits). Maybe somebody else is interested in helping out too?

Thanks!
Joost van Baal-Ilić
2014-12-15 15:50:01 UTC
Permalink
Hi again Svante,

On closer look of the proposed patch, I feel the tone is not right.
Text like

apt-get dist-upgrade Wheezy to Jessie will get systemd-sysv installed, and
sysvinit will be history!! Otherwise you need to install sysvinit-core on next
reboot (if your system boots).

is not suitable for our release notes. The release notes should emphasise
default or very common scenarios. We assume most of our users to go with our
new default choice of systemd. Those preferring other init systems might in
general be better helped by e.g. pointing to a wiki page. I agree with what
Osamu Aoki wrote on december 3, in slightly different context.

However, if you can supply _short_ and _simple_ instructions on how to upgrade
and keep the previously selected init-system, such instructions are likely
suitable.

I was a bit put off by your use of "!!". I believe the 2 quoted sentences
could better be dropped. Care to minimise and adjust the patch? Sorry for not
raising this earlier.

Bye,

Joost
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Svante Signell
2014-12-15 16:10:02 UTC
Permalink
Post by Joost van Baal-Ilić
Hi again Svante,
On closer look of the proposed patch, I feel the tone is not right.
Text like
apt-get dist-upgrade Wheezy to Jessie will get systemd-sysv installed, and
sysvinit will be history!! Otherwise you need to install sysvinit-core on next
reboot (if your system boots).
is not suitable for our release notes. The release notes should emphasise
default or very common scenarios. We assume most of our users to go with our
new default choice of systemd. Those preferring other init systems might in
general be better helped by e.g. pointing to a wiki page. I agree with what
Osamu Aoki wrote on december 3, in slightly different context.
However, if you can supply _short_ and _simple_ instructions on how to upgrade
and keep the previously selected init-system, such instructions are likely
suitable.
I was a bit put off by your use of "!!". I believe the 2 quoted sentences
could better be dropped. Care to minimise and adjust the patch? Sorry for not
raising this earlier.
Hi I trimmed the patch, less text now. However, the LILO comment is
still there. Do you want me to remove that one too?
Brian Potkin
2014-12-15 18:20:02 UTC
Permalink
Post by Svante Signell
Hi I trimmed the patch, less text now. However, the LILO comment is
still there. Do you want me to remove that one too?
A few other things should be considered for removal too.
Post by Svante Signell
+ It is also a good idea to install
+ <systemitem role="package"> sysvinit-core, sysvint and sysvinit-utils
+ </systemitem> as the first packages when upgrading.
I have explained in another post why this is bad idea for Wheezy users
of upstart who do not want to change. It isn't even a good idea when the
user wants to keep sysvinit. It is unnecessary advice and should be
omitted.
Post by Svante Signell
+ </para> </listitem>
+ <listitem> <para> apt-get upgrade from Wheezy to Jessie can boot
+ with init=/lib/sysvinit/init until the old sysvinit package
+ is removed by e.g. autoclean.
'autoclean' will not remove an installed package from the system.
Post by Svante Signell
+ <listitem> <para>
+ If you have a desktop environment installed, it is also
+ recommended to install <systemitem
+ role="package">systemd-shim</systemitem> to
</para>
+ <itemizedlist>
+ <listitem> <para>
+ assist apt and/or aptitude with the upgrade,
Why do apt/aptitude require assistance? They have the pinning file and
the dependencies of libpam-systemd to go on. If either of them get it
wrong it is a bug and to be reported.

This advice is superfluous.
Post by Svante Signell
+ </para> </listitem>
+ <listitem> <para> avoid getting <systemitem
+ role="package">systemd-sysv</systemitem> installed by mistake,
+ e.g. if you have forgotten to create the pinning file. </para>
Apt's resolver not working would be a bug. A user error would not be a
bug. The presence or absence of systemd-shim has no bearing on whether
systemd-sysv is installed.

This advice is technically incorrect and also superfluous.

Regards,

Brian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Joost van Baal-Ilić
2014-12-16 07:40:02 UTC
Permalink
Hi Svante,

Brian: thanks for your comments; I tend to agree.

I've just checked; the patch applies:

***@nusku:~/svn/release-notes% patch -p0 < /tmp/en_issues.dbk.patch
patching file en/issues.dbk
Hunk #1 succeeded at 206 (offset 28 lines).
Hunk #2 succeeded at 224 (offset 28 lines).
Hunk #3 succeeded at 235 (offset 28 lines).

.

Some more comments/issues with the patch:

Chapter 5. Issues to be aware of for jessie is about "Sometimes, changes
introduced in a new release have side-effects we cannot reasonably avoid, or
they expose bugs somewhere else. This section documents issues we are aware
of."

I feel tips on how to override the new default init system do not belong here.
Another place would likely be more suitable.

Why do you use an <itemizedlist>? I feel just putting the <listitem>s in normal
paragraphs is better.
Post by Brian Potkin
Post by Svante Signell
Hi I trimmed the patch, less text now. However, the LILO comment is
still there. Do you want me to remove that one too?
"grub will get a new menu entry to boot with init=/lib/sysvinit/init if
something goes wrong with the switch to systemd-sysv. If you are using some
other bootloader, e.g. LILO you are on your own."

Perhaps something like:

If you don't use grub as bootloader, but e.g. LILO, changing to grub before
upgrading to Jessie makes the upgrade more robust. During the migration from
SysV init to systemd, grub will have an entry init=/lib/sysvinit/init, in order
to keep the system bootable with the old SysV.

.
Post by Brian Potkin
A few other things should be considered for removal too.
<snip>
Post by Brian Potkin
Post by Svante Signell
+ </para> </listitem>
+ <listitem> <para> apt-get upgrade from Wheezy to Jessie can boot
+ with init=/lib/sysvinit/init until the old sysvinit package
+ is removed by e.g. autoclean.
'autoclean' will not remove an installed package from the system.
So just remove "by e.g. autoclean".
Post by Brian Potkin
Post by Svante Signell
+ <listitem> <para>
+ If you have a desktop environment installed, it is also
+ recommended to install <systemitem
+ role="package">systemd-shim</systemitem> to
</para>
+ <itemizedlist>
+ <listitem> <para>
+ assist apt and/or aptitude with the upgrade,
Why do apt/aptitude require assistance? They have the pinning file and
the dependencies of libpam-systemd to go on. If either of them get it
wrong it is a bug and to be reported.
This advice is superfluous.
I suggest something like: "The package <systemitem
role="package">systemd-shim</systemitem> implements interfaces needed by
desktop environment helpers expecting systemd-like functionality. The
packagemanagement system will install this package if you use such a desktop
environment without running systemd as init system."

Bye,

Joost
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Hendrik Boom
2014-12-20 04:00:02 UTC
Permalink
+ It is also a good idea to install
+ <systemitem role="package"> sysvinit-core, sysvint and sysvinit-utils
Might you mean sysvinit instead of sysvint ?
+ </systemitem> as the first packages when upgrading.
-- hendrik
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Niels Thykier
2015-03-29 15:00:02 UTC
Permalink
Control: tags -1 pending
Post by Svante Signell
[...]
Hi I trimmed the patch, less text now. However, the LILO comment is
still there. Do you want me to remove that one too?
Hi,

I have applied a minor patch to day based on your patch submitted here
(See attached).

First hunk was accepted as-is (modulo whitespace). From the rest, I
extracted some minor pieces if not already documented else where. In
particular:

* I documented that installing systemd-shim and sysvinit-core manually
might help APT and aptitude when the pin is in place.

* The part of keeping "sysvinit" for having a fallback init was dropped
as it (meanwhile) got covered in 4.1.4.2[4.1.4]. As the removal of
sysvinit does not happen automatically, I asserted this was
sufficient.

* The [4.1.4.2] section also covers how to reboot using sysvinit as
long as the bootloader supports changing the kernel command line
prior to booting. I know grub supports this and [1] suggests LILO
is also capable of doing this.

A review is welcome - in particular please let me know if there are
things I left out that you believe should be included regardless.

Thanks,
~Niels

[4.1.4]
https://www.debian.org/releases/jessie/amd64/release-notes/ch-upgrading.en.html#recovery

(The closest I could get to a direct link to 4.1.4.2)

[1] http://docstore.mik.ua/orelly/linux/lnut/ch04_05.htm
Brian Potkin
2014-12-14 17:10:02 UTC
Permalink
+ It is also a good idea to install
+ <systemitem role="package"> sysvinit-core, sysvint and sysvinit-utils
+ </systemitem> as the first packages when upgrading.
What is gained by doing this? If pinning is used sysvinit-core is
installed. If sysvinit-core is installed before a dist-upgrade is done
why bother with pinning?

Aren't sysvint and sysvinit-utils already on the system and upgraded
without doing anything special with them beforehand?

Regards,

Brian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Svante Signell
2014-12-15 12:20:02 UTC
Permalink
Post by Brian Potkin
+ It is also a good idea to install
+ <systemitem role="package"> sysvinit-core, sysvint and sysvinit-utils
+ </systemitem> as the first packages when upgrading.
What is gained by doing this? If pinning is used sysvinit-core is
installed.
Are you sure? I'm not. Pinning is a help for apt and aptitude to resolve
which packages to install.
Post by Brian Potkin
If sysvinit-core is installed before a dist-upgrade is done
why bother with pinning?
Other packages might install systemd-sysv by mistake? As was the case
with libpam-systemd before the Depends: of libpam-systemd was changed to
"systemd-shim | systemd-sysv"? Pinning helps you to avoid such mistakes.
Post by Brian Potkin
Aren't sysvint and sysvinit-utils already on the system and upgraded
without doing anything special with them beforehand?
Not sure about this either. Are you?
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Brian Potkin
2014-12-15 16:10:02 UTC
Permalink
Post by Svante Signell
Post by Brian Potkin
+ It is also a good idea to install
+ <systemitem role="package"> sysvinit-core, sysvint and sysvinit-utils
+ </systemitem> as the first packages when upgrading.
What is gained by doing this? If pinning is used sysvinit-core is
installed.
Are you sure? I'm not. Pinning is a help for apt and aptitude to resolve
which packages to install.
Here we both have in mind a Wheezy system with sysvinit (an essential
package). I am sure that the pinning will lead to sysvinit-core being
installed because of the dependencies of the init package.

For a system with upstart sysvinit is not installed (they conflict).
Such a system will not end up with systemd-sysv because of the pinning
and the dependencies of the init package.
Post by Svante Signell
Post by Brian Potkin
If sysvinit-core is installed before a dist-upgrade is done
why bother with pinning?
Other packages might install systemd-sysv by mistake? As was the case
with libpam-systemd before the Depends: of libpam-systemd was changed to
"systemd-shim | systemd-sysv"? Pinning helps you to avoid such mistakes.
Installing sysvinit-core first is fine if the Wheezy system has sysvinit
to begin with; the dependencies of the init package are then satisfied.

It would be a bad idea for upstart users to install sysvinit-core before
doing a dist-upgrade.
Post by Svante Signell
Post by Brian Potkin
Aren't sysvint and sysvinit-utils already on the system and upgraded
without doing anything special with them beforehand?
Not sure about this either. Are you?
I think you should become sure.

Regards,

Brian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Brian Potkin
2014-12-15 00:10:01 UTC
Permalink
+ If you have a desktop environment installed, it is also
+ recommended to install <systemitem
+ role="package">systemd-shim</systemitem> to
+ </para>
+ <itemizedlist>
+ <listitem> <para>
+ assist apt and/or aptitude with the upgrade,
+ </para> </listitem>
+ <listitem> <para>
+ avoid getting <systemitem role="package">systemd-sysv</systemitem>
+ installed by mistake.
Which DE would not install systemd-shim when the recommended pinning is
done? How can systemd-sysv be installed "by mistake" when the Depends:
of libpam-systemd include "systemd-shim | systemd-sysv"?

Regards,

Brian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Osamu Aoki
2014-12-03 13:10:01 UTC
Permalink
Hi,

Niels and Javi said well for release-notes and translation time-line
of installation-guide against the freeze.

If you are thinking of submitting a patch to installation-guide for the
following part, I reminds you few things to get it accepted.
196 <caution>
197 <para>
198 Be advised that some packages may have degraded behaviour or
@@ -33,3 +43,43 @@
207 role="package">systemd-sysv</systemitem> package must be
208 installed first.
209 </para>
+
+ <!-- New installations of Jessie -->
+ <title>How to avoid the default init system for Jessie</title>
+ <para>
+ For new installations of Jessie the default init system
+ systemd-sysvinit will be installed. In order to run a
+ traditional init system, such as sysvinit-core, two
+
+ <para>
+ 1) Go through the installation, selecting the minimum number
+ of packages, maybe do only select standard (or use
+ netinst.iso). After the installation and first reboot,
+ install sysvinit-core and remove systemd-sysv (and maybe
+ other *systemd* packages). If a desktop is to be
+ installed install systemd-shim first before choosing other
+ components.
+ </para>
+
+ <para>
+ 2) Use a preseed command to finish the install with
+ sysvinit-core instead of systemd-core. (again choosing a
+ minimum installation)
+ <screen>
+ Choose #### Advanced options
+ Choose ### Running custom commands during the installation
+ </screen>
+ Issue
+ <screen>
+ preseed/late_command="in-target apt-get install -y sysvinit-core"
+ </screen>
+ and continue with the installation.
+ For further info see
+ https://wiki.debian.org/systemd#Installing_without_systemd
+ and
+ <screen>
+ http://d-i.debian.org/manual/en.i386/apbs05.html
+ http://d-i.debian.org/manual/example-preseed.txt
+ </screen>
+ </para>
This is too long and the tone of text is not right.

Although you may not like it, the rule is that the non-default install
guide should not interfere with the guide for the default install
process. Also, you should avoid writing long "workaround instructions"
in the way which cause translation problems (There will be the last
minutes changes which obsolete such workarounds.)

I would suggest the following:

1. A short pointer text in appropriate main manual text pointing to the
appendix containing workaround. For example, right before
"6.3.4. Installing the Base System" propose to add
"*.*.*. Setting the init system" and you state there simply as:

| The default init system on the Debian <arch> system is <init-program>.
|
| You can override it using the preseeding (see B.2 Using the alternative
| init system).

(I am too lazy to gigure out how to set up <arch> and <init-program> in
XML and entity references.)

2. Add new section "B.2.6. Using the alternative init system"

| === Using the alternative init system ===
|
| You can specify the alternative init system, e.g. the classic sysvinit,
| to the debian-installer by passing preseed/late_command at the boot
| prompt:
|
| <screen>
| preseed/late_command="in-target apt-get install -y sysvinit-core"
| </screen>
|
| Please note some desktop environment may not be fully compatible with
| such non-standard init systems.


If you feel like adding some other workarounds, please make them as the
independent paragraph or list item. So each removal with some bug fix
should not cause translation updates. (Dropped English text will be
nicely synched via po4a.)

You may ask a patch to example-preseed.txt, too.

Quite frankly, HOWTO for switching already installed init system is off
topic and should not be included in installation-guide. You should
consider creating well organized text somewhere in wiki.debian.org if it
does not exist.

Good luck,

Osamu
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Adam D. Barratt
2014-12-03 21:10:02 UTC
Permalink
I will make a modified proposal to the actual document. However there
https://anonscm.debian.org/viewvc/ddp/manuals/trunk/
Why should there be?

The installation-guide package has Vcs-* headers. They work.

Regards,

Adam
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Debian Bug Tracking System
2015-03-29 15:20:01 UTC
Permalink
Post by Niels Thykier
tags -1 pending
Bug #771825 [release-notes] release-notes: Update information on non-systemd Jessie upgrades and installations
Added tag(s) pending.
--
771825: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771825
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-doc-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@bugs.debian.org
Debian Bug Tracking System
2016-05-14 14:10:02 UTC
Permalink
Your message dated Sat, 14 May 2016 13:45:50 +0000
with message-id <***@thykier.net>
and subject line Re: Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
has caused the Debian Bug report #771825,
regarding release-notes: Update information on non-systemd Jessie upgrades and installations
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)
--
771825: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771825
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
Loading...