Hi,

the new skeleton file shipped by initscripts (and in dh_make) makes use
of /lib/init/init-d-script.

This is problematic, because that means they get a hard dependency on
sysvinit-utils and we are currently trying to reduce the number of
packages in a minimal base installation.

One possible solution is to switch the skeleton file back to the old
version, which didn't use init-d-script, so new init scripts based on
the skeleton file do no pick up that dependency.

A middle ground would be, to make the skeleton file work more
gracefully, if a native sytemd .service file exists.
If we source /lib/lsb/init-functions *before* /lib/init/init-d-script,
packages which ship a native service file would continue to work even if
/lib/init/init-d-script doesn't exist.

The suggestion would be to remove ". /lib/lsb/init-functions" from
init-d-functions and into /etc/init.d/skeleton like this:

#!/bin/sh
# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing.
if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
    . /lib/lsb/init-functions
    set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
fi

Petter, do you have any preference regarding those two proposals or do
you have another suggestion how we could address this?

Regards,
Michael

Am 03.06.2016 um 13:35 schrieb Michael Biebl:

A side-effect of this particular change would be that this also fixes
#826214

Regards,
Michael

[Michael Biebl]

I wrote
<URL: http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html >
to explain the background for the init-d-script setup.

The goal is to avoid code in the individual init.d scripts that is not
_required_ to get them working, to make it possible to fix bugs in many
scripts by modifying one file.  Moving code from init-d-script to the
individual init.d scripts thus seem like a step backwards.

What about moving the init-d-script file to the same package containing
/lib/init/vars.sh, which is needed by most init.d scripts and should be
available on all Debian installations?  It seem like a better idea to
me.  The init-d-script approach is used by several packages in Debian
already.

Am 03.06.2016 um 23:54 schrieb Petter Reinholdtsen:

/lib/init/vars.sh is currently shipped by initscripts and we were
actually discussing that moving that to sysvinit-utils because moving it
to sysv-rc doesn't really work (see pitti's bug report in that regard).

This doesn't solve the problem though, that such SysV init scripts have
a hard dependency on a sysvinit provided package, even if they ship a
native service file and we'd have to keep that package installed forever
in the future.
The redirection of /etc/init.d/foo <action> to systemctl <action> foo
would fail otherwise.
We could accept that breakage, but maybe we can do better. Moving the
inclusion of /lib/lsb/init-functions before /lib/init/init-functions-d
was an idea in that regard.
Do you have any concerns regarding that change?

Michael

Hello.
[...]

Maybe I'm going further off-topic here, but have to ask something...

While I think that in theory init-d-script is a good idea, I have
some practical concerns about it being the default skeleton for now.

I agree that it would feel like a step backwards to revert to
the old skeleton, but at the same time as more packages pick up the
new skeleton they run into issues and there's no maintainer....

The only good thing I have to add about the old style is that atleast
it's well proven.... Personally I'd prefer if also init scripts where
something included in upstream collaboration, and wondering if that's
even possible with init-d-script (which I guess is only available in
Debian(-derivates))? There's also the question on where things should
live to avoid having all packages shipping an init script need to
depend on sysvinit. Also I doubt there will be any effort to convert
existing init scripts over to the new format so that it actually
gets the practical benefits of being able to fix many packages at once.
It's also risking becoming a situation where noone dares to touch the
"one place" (init-d-script itself) which affects all packages because
there's always something which breaks and given enough breakages people
will just move away from it. Having a good test-suite is as I see it
basically a requirement for doing these central backend code efforts,
cf. cdbs vs dh. People will quickly start relying on bug-compatibility
and implementation details when they need a solution to their problem
and there's noone around to quickly fix up the backend to work as
expected, see #825870 for a recent example of where I myself is guilty
of misleading someone into relying on implementation details
instead of using the (non-working) documented correct solution.

Each of these issues might be no big deal on their own but at the same
time it feels like there's bigger picture to be seen by someone thinking
about this system and how it would fit in both in Debians
multi-init-system world and how it would fit into upstream project
collaboration. That's not something that should be dealt with through
targeted NMUs in my opinion.

Until there's someone actively maintaining sysvinit (and init-d-script
in particular) I'd prefer we revert the skeleton back to the old version
for now. Opinions/Comments?

Regards,
Andreas Henriksson

Hi there,
(Cc'd a lot of people, so that hopefully everybody relevant
is included.)

Andreas Henriksson recently pointed me to the fact that there
are several problems with the current init-d-script in Debian
(which I use in my own packages to handle the non-systemd
cases), and he most prominently mentioned the problem that
with init-d-script systemctl redirection via direct calls to
the init script doesn't work properly (in contrast to normal
init scripts, where it does).

What bothered me is that many people (including Andreas) have
started suggesting not to use init-d-script because of its
problems but to rather use the previous template. I think
this is the wrong approach, because I'm perfectly happy in
maintaining something like:

http://sources.debian.net/src/open-isns/0.96-5/debian/open-isns-server.isnsd.init/
http://sources.debian.net/src/open-isns/0.96-5/debian/open-isns-discoveryd.isnsdd.init/

in my packages, but I would hate to have to maintain all of
the boilerplate code.

For this reason I promised Andreas that I'd take a closer look
at those and see what I can do.

I think I have a solution to both issues - and my solution
does not require any change to any individual init script,
and best of all it doesn't even require changes to any
sysvinit-related package (we get to have our cake and eat
it too):

The systemd package could install a diversion of
/lib/init/init-d-script and install its own wrapper. The
wrapper could check for systemd being run and properly handle
the redirect-to-systemctl case. On systems that have systemd
installed but are booted with something else the wrapper
would just source the original wrapper.

This has two distinct advantages:

 - diversions now work properly for init-d-scripts
   (fixes #826214)

 - scripts that use init-d-script _and_ have a native systemd
   service with the same name _and_ do _not_ implement custom
   verbs in the init script (do_unknown) don't need to depend
   on sysvinit-utils anymore. At the same time the entire
   init-d-script logic does _not_ need to be installed on
   such systems. (init-d-script packages without a native
   services still need the dependency though, as expected.)
   (fixes #826215)

I've developed a patch against current sid of the systemd
package and tested that on both systemd and sysvinit systems
extensively and made sure all of the code paths work.

The wrapper itself doesn't have much code, but I've added a
lot of comments to make sure that the corner cases (that are
all handled properly) are understood, so people modifying it
don't break it accidentally.

For the sysvinit people, to make it clear thst it doesn't
harmfully affect non-systemd systems: the basic structure of
the wrapper is the following:

#!/bin/sh
if [ -d /run/systemd/system ] ; then
  # do systemd-specific stuff
fi
. /lib/init/init-d-script.sysv
exit $?

I have tested the following (with real live packages):

 - systems booted with systemd, sysvinit-utils installed:
   redirection works as expected, custom verbs are still
   handled by init-d-script. The usage message is printed
   by the original init-d-script.

 - systems booted with systemd, sysvinit-utils not installed:
   redirection works as expected, the usage message is
   printed by the wrapper

 - systems booted with sysvinit, systemd not installed:
   everything still works

 - systems booted with sysvinit, systemd installed: the
   wrapper is a noop that just redirects to the original
   init-d-script

 - systems booted with sysvinit: installing a daemon,
   calling the init script, installing systemd (the package),
   calling the init script again, purging systemd, calling
   the init script yet again

I've done these tests multiple times with various different
packages and made sure I was hitting every code path of the
added code.

I've attached a git am'able patch against systemd's
debian/232-8 tag in git. Feedback welcome.

Regards,
Christian

PS: There is one corner case that is still open when it comes
to init-d-script and systemd, which is technically neither of
these bugs, but I feel I should mention it: if no native
systemd service is provided in addition to the init-d-script
init script, then systemd still doesn't properly detect
whether reload is possible for that service. I don't think
this is a huge issue, because that can easily be worked
around by providing a native systemd service in addition to
the init script. One could detect this properly by adding
support to detect this to systemd's sysv-generator (or add an
additional new generator), but I don't think that is worth
the effort.

Hello Christian,

Christian Seiler [2016-12-25 13:34 +0100]:

Thanks for working on this!

I don't like this approach, to be honest. (1) This diversion would be present
on practically all installs anyway, as it would (necessarily) be in the
"systemd" binary, not the "systemd-sysv" one. (2) I don't want to maintain this
SysV stuff in the systemd package forever, AND still have someone else maintain
the non-diverted variant in sysvinit-utils. I'd much prefer to just change the
"master" copy in sysvinit-utils, and packages which use that should grow a
dependency to that (so that it can become non-essential).

I. e. use your script but patch the current one instead of duplicating it.
If the SysV init maintainers don't want to carry this either, then there's
still the option to just drop the systemd integration, and break calling
/etc/init.d/foo directly under systemd. WDYT?

Thanks,

Martin

Hello Martin,
be able to remove the package. But if a lot of packages now depend on
it, then this will be installed on most installs regardless, so there's
no point in making the effort of making it non-essential. (Unless you
are really only interested in minimalistic base systems that aren't
really useful to anybody.)

What's the alternative? Michael proposed to go back to the old
template for init scripts in the initial bug report and basically drop
init-d-script from packages. As someone who maintains packages that
contain daemons, I strongly disagree: one of the appeals of systemd
(which I use and like btw.) is that service files are easy to read.
Same goes for init scripts that use init-d-script instead of what was
there previously, they are much easier to read than the horrible mess
that was there previously. His alternative proposal is much better,
but apparently not something the init-d-script people want, for
understandable reasons, and in addition both suggestions would
require that lots of consumers of init-d-script change their code.

In the end, you're just distributing a single additional script with
the systemd package. The maintenance burden is going to be essentially
zero, because the interface of init-d-script can't change without all
of the consumers having to be updated. I think the whole integration
that makes shutdown while switching init systems work is probably a
lot more work than shipping this file + the diversion, even if that
diversion is going to be installed on most systems. (Which I don't
consider to be a problem, just look at the fact that /bin/sh is a
diversion on nearly all installed Debian systems, which is a lot more
essential to a running system than init-d-script.)

Also, consider the following: with how I wrote this wrapper, if _all_
installed init scripts use init-d-script _and_ have native systemd
service equivalents, then /lib/lsb/init-functions and
/lib/init/vars.sh also don't have to be installed on systemd systems,
because the wrapper will also work in those cases and properly
redirect to systemctl there. You can then get rid of all of the
sysvinit packages in that case - and just carry two files in the
systemd package, /lib/lsb/init-functions.d/40-systemd and the
wrapper I created, for compatibility reasons. This will make it quite
a bit easier to reduce the amount of installed packages on the system.

Well, my script doesn't duplicate the init-d-script logic at all. It is
just some glue code hat hooks up the upcall to systemctl (but reuses
existing code for that), and falls back to the original implementation
if systemd isn't used (or another corner case is hit).
scripts in packages.

That all said: if you just want to fix #826214, I can also provide
a patch for the systemd package that updates
/lib/lsb/init-functions.d/40-systemd to properly work with
init-d-script - without you having to modify init-d-script or any
consumer thereof itself. But that won't help for #826215, when it
comes to how packages acquire dependencies on sysvinit-utils.

Regards,
Christian

Hello Christian,

Christian Seiler [2016-12-26  0:22 +0100]:

AFAIK init-d-script isn't being widely used, just by a handful of packages. But
you are right of course -- packages shouldn't depend on it because then you
couldn't uninstall sysvinit-utils under systemd. So instead, sysvinit-core
should depend on it, so that i-d-s is available under SysV. Without such a
dependency, under systemd calling /etc/init.d/foo would just throw an error,
but that's fine IMHO.

That would be more radical, but I don't actually object to the concept of a
generic SysV init script -- I just don't want to have it in the systemd
package, that's all :-) Hence my suggestion to just change the current version
in sysvinit-utils, instead of duplicating it. Why would that not work?

Right, but as you said under systemd you don't need any of those, and I don't
think it should be a long-term goal to keep the /etc/init.d/foo interface if
nothing from these scripts will actually be used -- that's what systemctl or
"service" are for, which are the official APIs to interact with system
services.

OK, right -- it calls the original diverted implementation. Still, this is too
much indirection and too hard to maintain IMHO.

To be honest, if I was to rule the world, I would just make sure that calling
/etc/init.d/foo cleanly errors instead of trying to do something undefined if
you call it under systemd. This should be a lot simpler to achieve without
diversions and three indirections. If that error is something like
"/lib/init/init-d-script not found", then that's at least well-defined (even
though it's not a very user friendly error, but *shrug* -- this is to prevent
accidental damage only).

I think it's actively harmful to pretend that this is an interface which is
both safe and sensible to keep for all eternity.. But let's agree to disagree. :-)

Thanks,

Martin

Hello Christian Seiler,
[...]

Not sure my opinion on this matter is relevant, but since you CCed me
here are my 5 (swedish) öre on this:

The problem I pointed you to where only one out of many symptoms of the
breakage introduced by using init-d-script. I think just attacking one
specific symptom of one specific LSB hook is wrong. What happens when
more LSB hooks also wants to use your solution? What happens when 5
different packages all try to divert init-d-script and then call each
other in a chain? This won't work or atleast won't be maintainable.

Following Martins advice and pushing this back into the original
init-d-script is better, because that means this is confined in a single
place. At the same time I think that's still wrong... you're still only
adding workarounds for one specific LSB hook.

At the same time for Buster it might be time to let go of this. Just
leave init-d-script broken in this regard (and hopefully find someone
willing to maintain it and handle its other issues). But in that case
I also think the systemd LSB hook should be changed from seamlessly
diverting to systemctl to instead print an error message advocating
invoke-rc.d or service and erroring out.

I also have to point out that I completely disagree with you on
minimal systems not being relevant to anyone. There's been much
work done on enabling more minimal systems for Stretch (which
now even supports being init-less). This is very useful for
containers. At the same time our inability to cater to this need
means we're rapidly losing ground to things like Alpine Linux which
does a better job at being small atleast.

Still, thanks for looking into this!

Regards,
Andreas Henriksson

PS. Likely doesn't make much difference but given sysvinit-utils is
so contentless these days making it non-essential in Buster would
still be a nice "cleanup" in my opinion. sysvinit-core already
has dependency in place (despite sysvinit-utils being essential).
Packages shipping init scripts using init-d-script should make sure
to also have a native systemd unit masking the init script.

Hello Andreas, all,

Andreas Henriksson [2016-12-27 10:49 +0100]:

"service", not invoke-rc.d, but I do agree that it would be better to
completely drop that magic. This would be a nice way to gradually teach people
about the init system neutral APIs, and also find/fix places which hardcode
calling /etc/init.d/.

Martin

[Martin Pitt]

Will service respect policy-rc.d?  I believe I saw some systemd service
failing to respect policy-rc.d in one of my chroots, and wonder if it
was a bug in some package or not (did not debug, had other priorities at
the time).

For the record, I believe the /etc/init.d/ scripts should keep working
also in the future, because I believe most of the around 1000 packages
with init.d scripts in Debian do not need to have their scripts replaced
and it is an advantage to have one common script across all the kernels
Debian supports.

It thus make me happy to see someone have time to work on improving the
init-d-script approach. :

Maintainer scripts (postinst, postrm, etc) in packages are to always use
invoke-rc.d, exceptions are almost always a package bug. Even when using
systemd.  The naming is unfortunate, yes.

But users and admins are to use service, and never invoke-rc.d.

And the systemd glue in invoke-rc.d is currently broken that it fails
to, by default, also stop related socket units, thus ensuring chaos if
activated midway during the unpack/configure steps.  A bug is already
open about it, but stalled.

Hi Andreas,


Sorry for not replying earlier, but I wanted to mull this over some
before answering.

So after reading your arguments I believe I agree with you.

Yes.
the Debian base smaller (I use containers myself and them
requiring less stuff is definitely something I look forward
to) - but since that was in support of an argument for
something I'm now convinced it's not the right way, I'm
going to leave it at that.





After reading the other emails, maybe we can converge on the
following consensus / compromise?

For stretch:

 - I'll provide a patch for #826214 against init-d-script
   that will restore the original arguments while sourcing
   /lib/lsb/init-functions. This will make systemctl
   redirection work again for Stretch when using
   init-d-script.

 - We'll ignore #826215 for Stretch and scripts shipping an
   init-d-script based init script will hard-depend on
   sysvinit-utils regardless of systemd service
   availability. (As they do now.)

 - Add a warning to the output in systemd's
   /lib/lsb/init-functions.d/40-systemd and mention that
   calling init scripts directly on systemd systems is
   deprecated. (I can provide a patch.)

For Buster:

 - We revisit #826215 and say that packages that provide a
   init-d-script that has the same name as a systemd service
   need not depend on sysvinit-utils, and that if people
   want init-d-scripts called directly in /etc/init.d
   (when a corresponding systemd service also exists) to
   work on systemd systems, they also have to install
   sysvinit-utils, otherwise this just breaks.

   People using service / invoke-rc.d will not have any
   trouble, and people who really want to call the script
   directly via /etc/init.d have to install an additional
   package. (Or use sysvinit as the init system.)

For either Buster or Buster + 1:

 - Revisit init.d script redirection entirely and perhaps
   get rid of it. (Or not, we'll have to see.)

Would at least the Stretch part of that be agreeable for
everyone involved here?

Regards,
Christian

PS: I've also gone through the bug list against init-d-script
and have been working on fixing a couple of other issues. I
haven't posted anything in that regard yet because I wanted to
wait what came out of this discussion here first, because this
is the most important issue at the moment.

No, by definition it won't (neither on sysvinit nor on systemd) - just like
/etc/init.d/foo start also does not respect policy-rc.d.

service is a tool for admins, and as such shouldn't be governed by
policy-rc.d. invoke-rc.d is a tool for maintainer scripts and as such
will be governed by policy-rc.d.

invoke-rc.d is basically the following logic (pseudo-shell):

if action is allowed for script by policy-rc.d ; then
  if [ -d /run/systemd/system ] ; then
    systemctl action scriptname.service
  elif ... upstart ... ; then
    ...
  else
    /etc/init.d/scriptname action
  fi
fi

service is basically the following logic (pseudo-shell):

if [ -d /run/systemd/system ] ; then
  systemctl action scriptname.service
elif ... upstart ...
  ...
else
  in_relatively_clean_context /etc/init.d/scriptname action
fi

In that case it's very likely a bug in the package's maintainer
script.

I don't think this is in question for now - but there are multiple layers
here:

 - what to do when only an init script is available and the service is
   to be started (e.g. at boot)

     => systemd will call the init script (and that will stay for a
        long time, even systemd upstream is not going to remove
        support for this anytime soon)

 - what to do when /etc/init.d/script action is called on the command
   line (instead of service script action or invoke-rc.d script action)

     => at the moment systemd installs some glue code to redirect this
        to systemctl, but that fails at the moment for init-d-script
        (this is #826214)

Pure egoism ;-) I really don't want to maintain boilerplate code in
my packages, so I like the idea behind init-d-script a lot, because it
makes it very easy for me to provide init scripts in additino to
systemd services (that nowadays are often provided by upstream).

Anyway, patches for #826214 and other issues will soon follow.

Regards,
Christian

Hi Christian,

Thanks for considering my negative feedback in a constructive way.
[....]

Looking forward to it.
sysvinit-utils is still Essential: yes and I think it's too late
to change that now for Stretch.
According to policy nothing should declare a dependency against
an essential package...

(Not sure this is needed, but no objection from me.)
Essential: yes from sysvinit-utils.
(Should be easily doable, but as always with these things
someone needs to make up a plan and consider all cases carefully.)

Installing sysvinit-utils manually will be the least of your
problem with invoking the init script directly unless the
LSB hook is there to redirect you to systemctl.

I think your explanation above is just too complicated for most
maintainers to spend enough time/thought about it to get it right.
Lets just say "if you use init-d-script provide a matching/masking
native systemd service unit" (and even if you don't use init-d-script
still provide a matching/masking systemd service unit anyway).
Much less complicated IMHO.

I think we can aim for this (and more!) for Buster.

HTH.

Thanks for your interest in building a good long-term
plan for these issues.

Regards,
Andreas Henriksson

Laba diena,


Noriu Jus informuoti apie šių metų pasikeitimą dėl atnaujintos visos Lietuvos įmonių bazės 2018 metų sausio vidurio.
Visi juridiniai asmenys pateikti bazėje yra veikiantys, realiai vykdantys veiklą, turintys įdarbintų darbuotojų. Duomenys pagal Sodrą, Registrų centrą.

Bazėje nurodoma ir apyvarta, darbuotojų atlyginimai, darbuotojų skaičius, transporto skaičius ir daug kitų duomenų, kuriuos matysite pavyzdyje.

Duomenis galima filtruoti pagal veiklas, miestus ir kitus duomenis.


Šią bazę verta turėti visoms įmonėms. Pateiksiu priežastis:

1) Kontaktai pateikti bazėje direktorių ir kitų atsakingų asmenų, didelė tikimybė Jums surasti naujų klientų, partnerių, tiekėjų, kai tiesiogiai bendrausite su direktoriais, komercijos vadovais.

2) Konkurentų analizavimas, tiekėjų atsirinkimas pagal Jums reikalingus kriterijus, galite atsifiltruoti pagal įmonės dydį, bazėje nurodoma kiek įmonės skolingos Sodrai.

3) Lengva, greita ir patogu dirbti su šia baze, elektroninius pašto adresus galite importuoti į elektroninių laiškų siuntimo programas ar sistemas iš kurių siunčiate elektroninius laiškus.
Taip pat galite importuoti mobiliųjų telefonų numerius į SMS siuntimo programas.


Išsirinkite iš "Veiklų sąrašo" veiklas kurių Jums reikia.
( Sąrašas prisegtas laiške excel faile )

Parašykite, kurias veiklas išsirinkote
ir atsiųsime pavyzdį ir pasiūlymą su sąlygomis įmonių bazei įsigyti



Pagarbiai,
Tadas Giedraitis
Tel. nr. +37067881041

OneDrive

Dеаг 826215@bugs.debian.org,

You received a new document.

Titled: "YourYearbook.pdf"


<https://1drv.ms/xs/s!AmDNkP4Av7YZgTh03pzLvm-GpkYl?wdFormId=%7B4872B095%2DC881%2D4DFF%2D919A%2D6E0D20ED6C9A%7D>

OneDrive Support

 

and
instead of the one in sysvinit-utils
The consensus (and probably the only consensus) was to wait until the
release happened, which it has so now is the time to decide.

The issue is how to get from here to there?
Also what is "there", does anything that has pidof need to be essential?

Most of the use-case for pidof is that /usr/lib/lsb/init-functions uses it
OR init scripts incorrectly use it.
Incorrectly for most because they probably should be using pidofproc()
(found in init-functions) instead.
From a dependency point of view, you get to the same point; needing pidof
directly or indirectly for most init scripts.

My reading is that you only need init-functions if you're using the init
files instead of the systemd unit files.
So there's no impact for a host running systemd with everything using unit
files if sysvinit-utils is removed.

However if both those criteria are not true then you need init-functions in
sysvinit-utils and therefore need
a pidof from somewhere.

Two paths here.

Path A: pidof stays in sysvinit-utils then we can keep going with the pidof
most other distros don't use and I'll close #810018.

Path B: We decide to use the procps pidof. Then there are two questions.
1) Should the procps pidof package be Essential?
2) Should the procps pidof package be separate to procps and libproc2?

My preference is for 1) the answer is no. This package would only be needed
because sysvinit-utils needs it, so a dependency should cover it.
The "main" procps package would probably need a dependency/recommends on it
just so pidof is there for users.

For 2) I have no real preference. Keeping pidof in main procps is easier
for me, but it does mean anything that needs sysvinit-utils
will pull in procps and its libraries. Most people would install procps
anyway but there might be a subsection that use sysvinit
and don't install procps; I have no idea what this number is. The breaking
out of pidof from procps would be for this intersection of users.

 - Craig

Sounds reasonable

Start without adding a new package which is operationally easier (no
new queue to clear) and see how it goes? It can always be added later,
if it turns out it's needed

I had a look into this and it seems the only valid required user of pidof
is /usr/lib/lsb/init-functions
Some init scripts call this, but they should be sourcing init-functions
(most do) and using pidofproc() (some do).
My understanding is the init-functions file is required for sysv init
scripts only.

So:
 * a sysv init system uses init scripts, which use init-functions, which
needs pidof
 * systemd init system uses unit files and doesn't need init-functions or
pidof

I'm not 100% sure of that second bullet point. I'd really like that
confirmed.

Does sysvinit-utils need to be Essential at all? Is it just merely making
sysvinit-core depend on sysvinit-utils (it does already)
and then sysvinit-utils requires whatever package has pidof?

Looking into it more and adjusting Helmut's suggested migration path[1]

Is it a matter of:
1) sysvinit-core depends on sysvinit-utils (already does with a version)
2) sysvinit-utils has its Essential tag removed, its being pulled in by
sysvinit-core
3) sysvinit-utils depends on and provides virtual package pidof
4) If there is anything that needs pidof but doesn't need sysvinit-utils it
also depends on virtual package pidof
5) At some time sysvinit-utils drops the virtual package, doesn't install
pidof, procps picks those up

Start without adding a new package which is operationally easier (no
Looking again at that small intersection. Having procps pidof by itself
would mean the (non systemd) sysctl isn't installed.
I'm not sure there are that many systems like that.

 - Craig


1: https://lists.debian.org/debian-devel/2023/11/msg00105.html

The second point is correct

The virtual package could also just be skipped, and a dependency utils
-> procps simply added, should provide the same results with fewer
steps in between?

Excellent, so a systemd init host doesn't need pidof then
That would work too and be less things going on.

sysvinit-utils/sysvinit-core maintainers, do you agree with this approach?
Do you need some dependent bugs opened, or is 826215 enough?

I'll wait a while for some replies. I think it needs to go to debian-devel.
Policy says it needs to go
there for new Essential packages, but I assume for removing Essential tags
it needs that too.

 - Craig

Craig,

Many thanks for the time and effort you have invested in this.
Surely pidof remains Essential until all such usages are identified and Depends:
whatever-pidof-provider added?

I think it is also worth considering that the 2 pidof implementations are not
completely identical. A brief comparison of the manpages suggests that the
separator option is different (-d vs -S) and some of the other options only
exist in 1 or other implementation.  If they are not direct drop-in
replacements, how do we avoid/handle breakage for callers/users?

Please be assured that I am not averse to finding a solution to this, but it is
a difficult issue requiring considerable work for pretty marginal gains. At the
moment, I don't see just removing Essential: yes from sysvinit-utils, shipping
pidof from src:procps' and adding the usual Breaks/Replaces as being a complete
and adequate transition plan.

With best wishes

Mark



[1]  https://sources.debian.org/src/dbus/1.16.2-2/debian/dbus.postinst#L46

Every affected package has now patches or MRs posted to solve the
problem, links in the salsa snippet.

As far as I can see nothing is left that needs pre-depends, after the
patches linked in the snippet above will be applied.