Hendrik Boom wrote on 26.07.2018 12:35: > On Wed, Jul 25, 2018 at 06:50:43PM +0200, Irrwahn wrote: >> Hendrik Boom wrote on 25.07.2018 17:59: >> [cut] >>> Package dependencies are of the form >>> Install X if Y is installed >>> Too bad it doesn't handle >>> Install X it Y and Z are installed. >>> I suspect, though, we don't wand to have to embed a SAT solver into the >>> package manager. It's already complicated enough. >> >> Hi Hendrik, >> >> I'm not entirely sure I correctly understand what you think that could >> accomplish. In case you meant it the way I _think_ you did, this would >> be my two cents worth of comment: >> >> It wouldn't help a bit, at least in the case at hand. The package >> dependency exists to make sure a library (here: libsystemd.so.0) the >> application (here: sshd) was linked against is present on the system, >> as otherwise the application would simply fail to start, which is >> undesirable. > > I was thinking about package Y, which has systemd init script in package Xd, > depend on package Xd only if systemd is present. > > No linking involved. > > But I agree that adding such a mechanism would greaty complicate the > package manager, likely beyond feasibility. Not worth it if it's only > to avoid a few small files that may never be used. >
Oh, you were talking about init scripts and unit files and the like, so I did get you wrong after all. I agree it's not worth it, for the reasons you gave. What's more, I'd go even further and say I wouldn't mind at all if every daemon package came with support for all init systems in current use (rc-style sysv|openrc, runit, ... , systemd), as that would make switching init systems in an already installed system much, much less of a pain in the rear. Why would I care about a few dozen tiny innocuous unused files on a system that per default install is already cluttered with literally thousands of files I'm never going to use in any way. That'd be what I'd call "init freedom". It's very unlikely to happen in the foreseeable future though, as it would require cooperative effort of hundreds of individuals to include and maintain those init support files in the respective packages. Regards, Urban -- Sapere aude!
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
