#799323 local-apt-repository: Uninstallable without systemd despite that seems supported according to the package description

#799323#5
Date:
2015-09-17 17:59:34 UTC
From:
To:
Hi Joachim,

the package description of local-apt-repository says:

  If you want to use this package on a system without systemd running,
  you will have to manually run /usr/lib/local-apt-repository/rebuild
  when you add new packages to /srv/local-apt-repository.

But local-apt-repository has a hard dependency on systemd and is hence
uninstallable on systems without systemd.

Hence the hard dependency on systemd should be downgraded to a
Recommends.

Maybe you could also use incron or inoticoming as alternative directory
watching tool on non-systemd systems.

                 Regards, Axel

#799323#10
Date:
2015-09-17 20:59:56 UTC
From:
To:
Hi,

Am Donnerstag, den 17.09.2015, 19:59 +0200 schrieb Axel Beckert:

I am a bit worried about the postinst scripts, in particular this part:

# Automatically added by dh_systemd_start
if [ -d /run/systemd/system ]; then
	systemctl --system daemon-reload >/dev/null || true
	deb-systemd-invoke start local-apt-repository.path >/dev/null || true
fi
# End automatically added section

Will this not break if systemd is not installed, but
/run/systemd/system is still around? But then it might be argued that
this would be a bug in dh_systemd_start.

If you are interested in supporting non-systemd-systems, would you mind
trying the change you want to see, test it, and send me a patch (or
even better: just change it in the git repo, which is in collab-maint)?

I’d prefer not adding complexity that is not required on default Debian
systems; I will however accept a patch (as required per #746715).

Greetings,
Joachim

#799323#15
Date:
2015-09-22 16:35:28 UTC
From:
To:
- rebuild with systemd moved to Recommends
- `mkdir -p /run/systemd/system' to test this situation
- dpkg -i local-apt-repository_0.2_all.deb

And that's how it looks like:

Selecting previously unselected package local-apt-repository.
(Reading database ... 413166 files and directories currently installed.)
Preparing to unpack .../local-apt-repository_0.2_all.deb ...
Unpacking local-apt-repository (0.2) ...
Setting up local-apt-repository (0.2) ...
Can't exec "systemctl": No such file or directory at /usr/bin/deb-systemd-helper line 542.
/var/lib/dpkg/info/local-apt-repository.postinst: line 38: systemctl: command not found
Can't exec "/bin/systemctl": No such file or directory at /usr/bin/deb-systemd-invoke line 88.
Use of uninitialized value $enabled_output in pattern match (m//) at /usr/bin/deb-systemd-invoke line 90.
Can't exec "/bin/systemctl": No such file or directory at /usr/bin/deb-systemd-invoke line 93.
local-apt-repository.path is a disabled or a static unit, not starting it.


Without /run/systemd/system there are no errors.

I guess an example or a howto in the README would be fine.


Cheers,
gregor

#799323#20
Date:
2020-05-18 01:43:07 UTC
From:
To:
The previous testing was misleading.

First of all, /run is a temporary folder:
 - https://www.debian.org/doc/debian-policy/ch-opersys.html#run-and-run-lock


we would only have  /run/systemd/system  if we booted with systemd.


However, if we were actively using systemd and tried to remove the
systemd package we would hit this code in prerm:

Thus the check of /run/systemd/system used by dh_systemd_start is
sufficient to ensure the init system to be systemd, in which case there
will be a systemctl.

A system with /run/systemd/system but no systemctl should probably be
considered broken. Specially given that the check
for /run/systemd/system existence appears in multiple places and
packages.


Moving systemd dependency to Recommends should be perfectly safe.

#799323#25
Date:
2020-08-19 06:21:17 UTC
From:
To:
Hi, any update here? I rebuilt the 0.6 package to remove the dependency on systemd
and it works fine in my systemd-less system (though I had to manually run the
rebuild script everytime I add new packages to the repository). Can you please
remove the Depends on systemd? In fact such package like this shouldn't be
depending on an init system in the first place...

In fact I would consider this an RC-bug, because according to policy Depends
should only be used if it is required to provide a *significant* amount of
functionality, which doesn't seem the case here.

Job Bautista

#799323#32
Date:
2020-08-27 18:44:08 UTC
From:
To:
Hi,

Am Mittwoch, den 19.08.2020, 06:21 +0000 schrieb Job Bautista:

I consider this (not having to manually run the rebuild script) central
functionality of local-apt-repository: The goal is that the user has to
worry about nothing but dropping apt files in the right directory. I
only know how to achieve this easily with systemd.

That said, I am not using it myself these days and am happy to yield
upstream and debian maintenance to anyone who cares more about this
package.

Cheers,
Joachim

#799323#37
Date:
2020-08-31 01:07:08 UTC
From:
To:
To be fair, I hadn't noticed the magic behavior.

This part is simple on this package just because systemd is doing the
heavy lifting. It would be possible to by using for instance fswatch
ran from an init daemon, but it isn't too clean (plus, it seems to loop
by also detecting accesses by rebuild).

Probably the best way would be to hook apt update to perform the
rebuild there if needed.

Regards