Hi, > > So far, the package fakemachine Depends on systemd, and that was enough. > > Now with the split, and since we need systemd-resolved, we should make > > fakemachine Depend on systemd-resolved as well. However, and if I > > understand properly, installing systemd-resolved also *enables* it. A > > user installing the package is saying: I want name resolution to be done > > by systemd-resolved. Therefore it's not really suitable to put it in a > > Depend or a Recommend. fakemachine only needs the code from > > systemd-resolved (lib and binary, I suppose), but it definitely doesn't > > want to enable it: this decision belongs to the user. > > > > Does that make sense so far?
Many times I have got the same feeling/need about packages like apache2, tomcat, etc. I would like to install and maintain them up-to-date using their Debian package distribution, but having a facility to not activate their (default) root/system- land and provide a facility for a user-land activation. In general it is possible in fact, I have achieved such for at least the two apache2 and tomcat ones. I mean for such packages providing a way to activate them-self in the root/system-land as well as a (general?) facility for a user- land service. I know that having a general approach to solve this is somehow infeasible. But despite this could it be really interesting (at least for my pov) to think about it and therefore a good candidate for a grow-your-idea-for- Debian-Project ticket? Best, Patrice _______________________________________________ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
