Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #195378 > unrolled thread

pointless systemd dependencies

Back to article view | Back to linux.debian.user

Contents

  pointless systemd dependencies David Griffith <dave@661.org> - 2018-05-07 04:10 +0200
    Re: pointless systemd dependencies Andy Smith <andy@strugglers.net> - 2018-05-07 06:00 +0200
    Re: pointless systemd dependencies <tomas@tuxteam.de> - 2018-05-07 08:10 +0200
      Re: pointless systemd dependencies David Griffith <dave@661.org> - 2018-05-07 08:50 +0200
        Re: pointless systemd dependencies tomas@tuxteam.de - 2018-05-07 09:20 +0200
        Re: pointless systemd dependencies Andy Smith <andy@strugglers.net> - 2018-05-07 10:00 +0200
          Re: pointless systemd dependencies David Griffith <dave@661.org> - 2018-05-07 10:40 +0200
            Re: pointless systemd dependencies <tomas@tuxteam.de> - 2018-05-07 12:30 +0200
      Re: pointless systemd dependencies "Michelle Konzack" <linux4michelle@tamay-dogan.net> - 2018-05-07 20:10 +0200
        Re: pointless systemd dependencies <tomas@tuxteam.de> - 2018-05-07 20:50 +0200
          Re: pointless systemd dependencies "Michelle Konzack" <linux4michelle@tamay-dogan.net> - 2018-05-08 11:50 +0200
    Re: pointless systemd dependencies The Wanderer <wanderer@fastmail.fm> - 2018-05-07 14:00 +0200
      Re: pointless systemd dependencies David Griffith <dave@661.org> - 2018-05-07 15:10 +0200
        Re: pointless systemd dependencies songbird <songbird@anthive.com> - 2018-05-07 21:20 +0200
          Re: pointless systemd dependencies Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-05-08 05:30 +0200
        Re: pointless systemd dependencies Brian <ad44@cityscape.co.uk> - 2018-05-07 21:20 +0200
          Re: pointless systemd dependencies David Griffith <dave@661.org> - 2018-05-08 00:30 +0200
      Re: pointless systemd dependencies Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-07 21:00 +0200
        Re: pointless systemd dependencies The Wanderer <wanderer@fastmail.fm> - 2018-05-08 05:20 +0200
          Re: pointless systemd dependencies Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-08 11:10 +0200

#195378 — pointless systemd dependencies

Could we start the process of identifying packages that have dependencies 
on systemd in some way that is are not actually required?

-- 
David Griffith
dave@661.org

A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[toc] | [next] | [standalone]

#195384

Hello,

On Mon, May 07, 2018 at 01:47:51AM +0000, David Griffith wrote:
> Could we start the process of identifying packages that have dependencies on
> systemd in some way that is are not actually required?

Nothing has been stopping anyone from doing this since the day the
first package in Debian required systemd. Have at it. Report bugs in
the Debian bug tracker. Use the "reportbug" tool.

However…

I don't think that you will find that many packages that currently
depend upon systemd where this is a real bug.

Do you have examples of such packages where the bugs have not been
filed yet?

Several issues:

- If a package works better/differently in the presence of systemd
  then a depend on systemd may be appropriate, if upstream doesn't
  want to support other inits. You can't generally expect Debian to
  deviate very far from upstream.

- A lot of packages depend upon libsystemd0 just to detect the
  presence of systemd but work fine without systemd-as-pid1. A
  dependency on libsystemd0 here is appropriate; it doesn't mean you
  have to run systemd-as-pid1.

- Some upstreams don't implement a sysV init script or have removed
  the ones they had, because they only want to support systemd init
  scripts. While it might be nice for Debian to expend effort to go
  further than the upstream author does, it's not always feasible or
  desirable, so a bug to (re-)add sysV init script support may end
  up as wontfix or wishlist for an indefinite period.

Between this and more complications I'd be surprised if there are
many packages which directly depend upon systemd-as-pid1 for no good
reason. But do report bugs for those that do!

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#195388

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, May 07, 2018 at 01:47:51AM +0000, David Griffith wrote:
> 
> Could we start the process of identifying packages that have
> dependencies on systemd in some way that is are not actually
> required?

David,

I understand your concerns. I, myself don't like systemd. But *if*
you actually want something changed, you'll have to pick up some
legwork yourself, like, for example, understand what libsystemd
is actually doing in some package of your choice.

But first of all, you'll have to accept that there are folks out
there (who are at least as smart as you and me) who do like systemd,
and that packagers want to cater to those folks as well. So if some
binary wants to be able to work with systemd when it's there, perhaps
linking against libsystemd is the right thing to do. A package
maintainer won't keep around two versions of her package, one compiled
against libsystemd and another without it. Especially because that
doesn't scale well: someone might not like libdbus, someone else
quibbles about libselinux -- and we are already at eight binary
versions for one executable.

Sometimes binary distributions do have a cost, convenient as they
are.

If "no systemd" purism is your thing, there's Devuan. There are
pretty smart folks over there too. 

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlrv5/wACgkQBcgs9XrR2kZHRgCfYfgo6yH27+Sx2vrjqTvhl8Se
zEsAn1dREi1BAYyI4VIs0aWWfm9gv1HT
=wL3v
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#195391

On Mon, 7 May 2018, tomas@tuxteam.de wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, May 07, 2018 at 01:47:51AM +0000, David Griffith wrote:
>>
>> Could we start the process of identifying packages that have
>> dependencies on systemd in some way that is are not actually
>> required?
>
> David,
>
> I understand your concerns. I, myself don't like systemd. But *if*
> you actually want something changed, you'll have to pick up some
> legwork yourself, like, for example, understand what libsystemd
> is actually doing in some package of your choice.
>
> But first of all, you'll have to accept that there are folks out
> there (who are at least as smart as you and me) who do like systemd,
> and that packagers want to cater to those folks as well. So if some
> binary wants to be able to work with systemd when it's there, perhaps
> linking against libsystemd is the right thing to do. A package
> maintainer won't keep around two versions of her package, one compiled
> against libsystemd and another without it. Especially because that
> doesn't scale well: someone might not like libdbus, someone else
> quibbles about libselinux -- and we are already at eight binary
> versions for one executable.
>
> Sometimes binary distributions do have a cost, convenient as they
> are.
>
> If "no systemd" purism is your thing, there's Devuan. There are
> pretty smart folks over there too.

How many packages are there that could possibly need to be linked against 
systemd?

-- 
David Griffith
dave@661.org

A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[toc] | [prev] | [next] | [standalone]

#195393

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, May 07, 2018 at 06:32:16AM +0000, David Griffith wrote:
> On Mon, 7 May 2018, tomas@tuxteam.de wrote:

[...]

> How many packages are there that could possibly need to be linked
> against systemd?

I don't know what your question has to do with what we were discussing
above, but here you go:

  tomas@trotzki:~$ apt rdepends libsystemd0 | wc -l
  152

(slightly edited). Start there, pick one, and start working :-)

Oh, and to get an idea of the rough order of magnitude:

  tomas@trotzki:~$ apt rdepends libc6 | wc -l
  19461

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlrv+MsACgkQBcgs9XrR2kb6kQCffqtojSU2hNBYfpa5pxShNBFt
oX4AnRmcPP/cnxdSsBXsRm3zkuHCb6HL
=OcrO
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#195395

Hi David,

On Mon, May 07, 2018 at 06:32:16AM +0000, David Griffith wrote:
> How many packages are there that could possibly need to be linked against
> systemd?

Are you going to provide us with any examples of packages you think
are needlessly linked against systemd? I expect there are some, but
depending on whether they are easy or hard to find would seem like
an easy first step in working out if this is a serious problem or
not.

Cheers,
Andy

[toc] | [prev] | [next] | [standalone]

#195397

On Mon, 7 May 2018, Andy Smith wrote:

> Hi David,
>
> On Mon, May 07, 2018 at 06:32:16AM +0000, David Griffith wrote:
>> How many packages are there that could possibly need to be linked against
>> systemd?
>
> Are you going to provide us with any examples of packages you think
> are needlessly linked against systemd? I expect there are some, but
> depending on whether they are easy or hard to find would seem like
> an easy first step in working out if this is a serious problem or
> not.

tomas@tuxteam.de pointed out how to get a list of packages that link to 
libsystemd0.  I'll use that as a starting point.

-- 
David Griffith
dave@661.org

A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[toc] | [prev] | [next] | [standalone]

#195398

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, May 07, 2018 at 08:15:41AM +0000, David Griffith wrote:
> On Mon, 7 May 2018, Andy Smith wrote:
> 
> >Hi David,
> >
> >On Mon, May 07, 2018 at 06:32:16AM +0000, David Griffith wrote:
> >>How many packages are there that could possibly need to be linked against
> >>systemd?
> >
> >Are you going to provide us with any examples of packages you think
> >are needlessly linked against systemd? I expect there are some, but
> >depending on whether they are easy or hard to find would seem like
> >an easy first step in working out if this is a serious problem or
> >not.
> 
> tomas@tuxteam.de pointed out how to get a list of packages that link
> to libsystemd0.  I'll use that as a starting point.

Ah, now I understand. Looking forward :)

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlrwJM8ACgkQBcgs9XrR2kZVRgCeKWt8ZgEoIiwL9Ph+JpEqywQ2
UyEAn0NZFRKGaTMt+vHQJlru8RjRu5FE
=XkO0
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#195445

Good evening,

Am 2018-05-07 hackte tomas@tuxteam.de in die Tasten:
> If "no systemd" purism is your thing, there's Devuan. There are
> pretty smart folks over there too.

Without security updates...

I used some to get rid of systemd entirely, BUT,
those packages are some versions behind Debian!

Thanks

-- 
Michelle Konzack        Miila ITSystems @ TDnet
GNU/Linux Developer     00372-54541400

[toc] | [prev] | [next] | [standalone]

#195448

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, May 07, 2018 at 08:49:00PM +0300, Michelle Konzack wrote:
> Good evening,
> 
> Am 2018-05-07 hackte tomas@tuxteam.de in die Tasten:
> > If "no systemd" purism is your thing, there's Devuan. There are
> > pretty smart folks over there too.
> 
> Without security updates...
> 
> I used some to get rid of systemd entirely, BUT,
> those packages are some versions behind Debian!

This is to be expected: keeping a distro up to date is real work.
They surely could use some help (hint, hint).

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlrwmtAACgkQBcgs9XrR2kahvQCfUEelJ9vQNNKnqrkaII1ckHiV
eRYAnAp/asEvEkbAsDVtnu/3dUxjDdst
=QCpi
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#195485

Hi,

Am 2018-05-08 hackte tomas@tuxteam.de in die Tasten:
> On Mon, May 07, 2018 at 08:49:00PM +0300, Michelle Konzack wrote:
>> Without security updates...
>>
>> I used some to get rid of systemd entirely, BUT,
>> those packages are some versions behind Debian!
>
> This is to be expected: keeping a distro up to date is real work.
> They surely could use some help (hint, hint).

Currently absolutely no chance!

I am co-owńer of "Miila Mahe Aed OÜ" (Miila Organic Garden Ltd)
<https://www.miila-mahe-aed.eu/> and have the hell of work on the
neck!  And in the coming Winter I will work on the "Miila Rohe-Energia
Süsteemid Foundation" (Miila Green-Energy Systems Foundation) and I
have not even time to work on a preliminary Website
<http://www.miila-rohe-energia-systeemid.eu/> which has international
character and OpenSource.

So I can not care about foreign programming issues.

Thanks in advance

-- 
Michelle Konzack        Miila ITSystems @ TDnet
GNU/Linux Developer     00372-54541400

[toc] | [prev] | [next] | [standalone]

#195401

[Multipart message — attachments visible in raw view] — view raw

On 2018-05-06 at 21:47, David Griffith wrote:

> Could we start the process of identifying packages that have
> dependencies on systemd in some way that is are not actually
> required?

This is a seriously nontrivial task.

As I understand matters, the only sure way to do it would be something like:

1. Start with a systemd-free computer.

2. Attempt to install a package.

3. See whether it tries to install systemd, either by direct dependency
or by an indirect cascade of dependencies.

4. If it tries to install systemd by direct dependency, analyze the
source and functionality of the package, to determine whether or not
there would be a way to get it to do what it needs to do without
referencing systemd in a way which would require the dependency.

5. If it tries to install systemd by indirect dependency, identify the
package in the dependency chain which results in pulling in systemd, and
then either:

5a. Analyze that package in the same way as under step 4.

5b. Analyze the package above that one in the dependency chain to
determine whether or not it can be made to do what it needs to do
without referencing that package in a way which would require the
dependency.

5.b.1. If not, repeat step 5b for the next package up the chain, and
keep repeating for as many packages are in the chain.

6. Repeat from step 2 with another package, until every package has been
checked.

And all of that is just to identify the packages in question. Modifying
them to remove the dependencies would be another nontrivial task in many
cases; getting the package maintainer to accept patches which do so
would be still another nontrivial task.


I did notice when one package which I run on my primary (systemd-free)
computer developed an indirect dependency on libpam-systemd (as part of
fixing an arguably minor bug in a feature I don't use), reported that as
a possible unintended result to the maintainer (asking whether there was
any possibility of a way forward which wouldn't require me to build that
package locally going forward in order to avoid systemd), and was
fortunate enough that the maintainer found an alternative dependency
which would avoid the indirect chain to libpam-systemd.

But that was something I noticed in the course of checking a routine
dist-upgrade, not the result of embarking on a project to analyze the
archive in search of such packages - and even then, I was lucky that A:
an alternative solution could be found and B: the maintainer was
sufficiently non-unsympathetic to the desire to avoid systemd to be
willing to look for and implement one.


All of which is to say: I am not at all certain that this project would
be at all worth the time and effort it would require.

But I am not one to tell others not to do work they think is beneficial.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#195413

[Multipart message — attachments visible in raw view] — view raw

On May 7, 2018 4:39:22 AM PDT, The Wanderer <wanderer@fastmail.fm> wrote:
>On 2018-05-06 at 21:47, David Griffith wrote:
>
>> Could we start the process of identifying packages that have
>> dependencies on systemd in some way that is are not actually
>> required?
>
>This is a seriously nontrivial task.
>
>As I understand matters, the only sure way to do it would be something
>like:
>
>1. Start with a systemd-free computer.
>
>2. Attempt to install a package.
>
>3. See whether it tries to install systemd, either by direct dependency
>or by an indirect cascade of dependencies.
>
>4. If it tries to install systemd by direct dependency, analyze the
>source and functionality of the package, to determine whether or not
>there would be a way to get it to do what it needs to do without
>referencing systemd in a way which would require the dependency.
>
>5. If it tries to install systemd by indirect dependency, identify the
>package in the dependency chain which results in pulling in systemd,
>and
>then either:
>
>5a. Analyze that package in the same way as under step 4.
>
>5b. Analyze the package above that one in the dependency chain to
>determine whether or not it can be made to do what it needs to do
>without referencing that package in a way which would require the
>dependency.
>
>5.b.1. If not, repeat step 5b for the next package up the chain, and
>keep repeating for as many packages are in the chain.
>
>6. Repeat from step 2 with another package, until every package has
>been
>checked.
>
>And all of that is just to identify the packages in question. Modifying
>them to remove the dependencies would be another nontrivial task in
>many
>cases; getting the package maintainer to accept patches which do so
>would be still another nontrivial task.
>
>
>I did notice when one package which I run on my primary (systemd-free)
>computer developed an indirect dependency on libpam-systemd (as part of
>fixing an arguably minor bug in a feature I don't use), reported that
>as
>a possible unintended result to the maintainer (asking whether there
>was
>any possibility of a way forward which wouldn't require me to build
>that
>package locally going forward in order to avoid systemd), and was
>fortunate enough that the maintainer found an alternative dependency
>which would avoid the indirect chain to libpam-systemd.
>
>But that was something I noticed in the course of checking a routine
>dist-upgrade, not the result of embarking on a project to analyze the
>archive in search of such packages - and even then, I was lucky that A:
>an alternative solution could be found and B: the maintainer was
>sufficiently non-unsympathetic to the desire to avoid systemd to be
>willing to look for and implement one.
>
>
>All of which is to say: I am not at all certain that this project would
>be at all worth the time and effort it would require.
>
>But I am not one to tell others not to do work they think is
>beneficial.
>
>-- 
>   The Wanderer
>
>The reasonable man adapts himself to the world; the unreasonable one
>persists in trying to adapt the world to himself. Therefore all
>progress depends on the unreasonable man.         -- George Bernard
>Shaw

I found someone who has already done most if not all of this analysis and has set up a repo containing non-systemd-using packages.  Perhaps this can be used as a foundation for something official.
-- 
David Griffith
dave@661.org

[toc] | [prev] | [next] | [standalone]

#195450

David Griffith wrote:
...
> I found someone who has already done most if not all of this analysis and =
> has set up a repo containing non-systemd-using packages=2E  Perhaps this ca=
> n be used as a foundation for something official=2E

  devuan is already there (is it not?)...


  songbird

[toc] | [prev] | [next] | [standalone]

#195478

[Multipart message — attachments visible in raw view] — view raw

On 08/05/18 04:52, songbird wrote:
> David Griffith wrote:
> ...
>> I found someone who has already done most if not all of this analysis and =
>> has set up a repo containing non-systemd-using packages=2E  Perhaps this ca=
>> n be used as a foundation for something official=2E
> 
>   devuan is already there (is it not?)...

Devuan is great, but if upstream packages rely unnecessarily on systemd
for any reason, then those packages may or may not have a port that is
sans systemd.  An alternative competing option may be necessary if the
"bad" package cannot be used sans systemd as required.

What we are looking at here [at a minimum] is to remove dependencies
that are actually there due to laziness rather than actually being
required; which is quite different.  If there is a "real" dependency,
then that needs to be coded around to fix it, if it, in fact, can be
coded around... which would take more work (possibly much more work).

Kind Regards
AndrewM

[toc] | [prev] | [next] | [standalone]

#195451

On Mon 07 May 2018 at 05:50:27 -0700, David Griffith wrote:

> On May 7, 2018 4:39:22 AM PDT, The Wanderer <wanderer@fastmail.fm> wrote:
> >On 2018-05-06 at 21:47, David Griffith wrote:
> >
> >> Could we start the process of identifying packages that have
> >> dependencies on systemd in some way that is are not actually
> >> required?
> >
> >This is a seriously nontrivial task.
> >
> >As I understand matters, the only sure way to do it would be something
> >like:
> >
> >1. Start with a systemd-free computer.
> >
> >2. Attempt to install a package.
> >
> >3. See whether it tries to install systemd, either by direct dependency
> >or by an indirect cascade of dependencies.
> >
> >4. If it tries to install systemd by direct dependency, analyze the
> >source and functionality of the package, to determine whether or not
> >there would be a way to get it to do what it needs to do without
> >referencing systemd in a way which would require the dependency.
> >
> >5. If it tries to install systemd by indirect dependency, identify the
> >package in the dependency chain which results in pulling in systemd,
> >and
> >then either:
> >
> >5a. Analyze that package in the same way as under step 4.
> >
> >5b. Analyze the package above that one in the dependency chain to
> >determine whether or not it can be made to do what it needs to do
> >without referencing that package in a way which would require the
> >dependency.
> >
> >5.b.1. If not, repeat step 5b for the next package up the chain, and
> >keep repeating for as many packages are in the chain.
> >
> >6. Repeat from step 2 with another package, until every package has
> >been
> >checked.
> >
> >And all of that is just to identify the packages in question. Modifying
> >them to remove the dependencies would be another nontrivial task in
> >many
> >cases; getting the package maintainer to accept patches which do so
> >would be still another nontrivial task.
> >
> >
> >I did notice when one package which I run on my primary (systemd-free)
> >computer developed an indirect dependency on libpam-systemd (as part of
> >fixing an arguably minor bug in a feature I don't use), reported that
> >as
> >a possible unintended result to the maintainer (asking whether there
> >was
> >any possibility of a way forward which wouldn't require me to build
> >that
> >package locally going forward in order to avoid systemd), and was
> >fortunate enough that the maintainer found an alternative dependency
> >which would avoid the indirect chain to libpam-systemd.
> >
> >But that was something I noticed in the course of checking a routine
> >dist-upgrade, not the result of embarking on a project to analyze the
> >archive in search of such packages - and even then, I was lucky that A:
> >an alternative solution could be found and B: the maintainer was
> >sufficiently non-unsympathetic to the desire to avoid systemd to be
> >willing to look for and implement one.
> >
> >
> >All of which is to say: I am not at all certain that this project would
> >be at all worth the time and effort it would require.
> >
> >But I am not one to tell others not to do work they think is
> >beneficial.
> >
> >-- 
> >   The Wanderer
> >
> >The reasonable man adapts himself to the world; the unreasonable one
> >persists in trying to adapt the world to himself. Therefore all
> >progress depends on the unreasonable man.         -- George Bernard
> >Shaw
> 
> I found someone who has already done most if not all of this analysis
> and has set up a repo containing non-systemd-using packages.  Perhaps
> this can be used as a foundation for something official.

Someone might be motivated if they could find what you are referring to.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#195465

On Mon, 7 May 2018, Brian wrote:
[snip notes on analysing each and every systemd-touching package]
>> I found someone who has already done most if not all of this analysis
>> and has set up a repo containing non-systemd-using packages.  Perhaps
>> this can be used as a foundation for something official.
>
> Someone might be motivated if they could find what you are referring to.

http://angband.pl/deb/archive.html

This is nowhere near as radical as the Devuan approach and is something I 
think can be pulled into Debian proper without much hassle.


-- 
David Griffith
dave@661.org

A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[toc] | [prev] | [next] | [standalone]

#195449

On Mon, 07 May 2018 07:39:22 -0400 The Wanderer said:

> 3. See whether it tries to install systemd, either by direct dependency
> or by an indirect cascade of dependencies.
... 
> 5. If it tries to install systemd by indirect dependency, identify the
> package in the dependency chain which results in pulling in systemd, and

~$ apt-cache rdepends libsystemd0 systemd

Regards
-- 
Abdullah Ramazanoğlu

[toc] | [prev] | [next] | [standalone]

#195477

[Multipart message — attachments visible in raw view] — view raw

On 2018-05-07 at 14:34, Abdullah Ramazanoğlu wrote:

> On Mon, 07 May 2018 07:39:22 -0400 The Wanderer said:
> 
>> 3. See whether it tries to install systemd, either by direct
>> dependency or by an indirect cascade of dependencies.
> ...
>> 5. If it tries to install systemd by indirect dependency, identify
>> the package in the dependency chain which results in pulling in
>> systemd, and
> 
> ~$ apt-cache rdepends libsystemd0 systemd

At a glance, this appears to only list the packages which directly
depend on libsystemd0 or systemd.

I'm thinking of multi-step dependency chains. The one which I mentioned
having noticed, reported, and gotten the maintainer to find a way to
drop, was four packages long:

[the original package] -> gvfs -> gvfs-daemons -> udisks2 -> libpam-systemd

The final step of which which is not systemd itself, but does introduce
behavior changes which I find undesirable, even with systemd not
present.

I don't know of any single command - or even self-contained set of
readily reusable commands - which would have identified the fact that
installing the original package would have pulled in libpam-systemd,
except for trying to install it. Even once that's been determined, I
don't know of any way to determine what part of the dependency chain
results in that happening, except to 'apt-get install [packagename]
libpam-systemd-' (and repeat, adding more "no, don't install this
package either" blockings of alternative dependency resolutions, until
the resolver fails to find a solution).

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#195483

On Mon, 07 May 2018 22:56:36 -0400 The Wanderer said:

> I don't know of any single command - or even self-contained set of readily
> reusable commands - which would have identified the fact that installing the
> original package would have pulled in libpam-systemd, except for trying to
> install it.

I think a makeshift script can be put together to query the "rdepends" tree up
recursively. It might result in quite crowded list. This is the simple part of
it.

But then, having the full dependency genealogy tree, each forward dependency
(including non-systemd dependencies) would have to be analysed for its
relevancy (really needed or not). This is the difficult part.

E.g. in your example,

> [the original package] -> gvfs -> gvfs-daemons -> udisks2 -> libpam-systemd

there are 4 relevancy tests to be done.

What I am trying to say is that, this needs to be solved at packaging level.
Or, IOW, distribution level. Packages should only "Depends" on absolutely
needed dependencies. All the others should be left to "Recommends" and
recommendations should not be treated as dependencies by default installation.
(APT::Install-Recommends "false")

I think that,
* Depending on probably or conditionally needed packages is the easy way.
* Treating recommendations as dependencies is the easy way again.

These could be solved by package installation scripts or a sophisticated
-possibly external- package management helper. This is a hard job to tackle
(working out actual dependencies correctly without going too chatty). Perhaps
apt needs to get a bit more sophisticated. This is a different topic.

When such knots are cascaded at packaging level (where it's relatively easier
to solve) undoing these knots at the user level is so inefficient that it is
almost equivalent to forking a new distro.

Regards
-- 
Abdullah Ramazanoğlu

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web