| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 26 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 04:11:32 |
| Calls: | 483 |
| Calls today: | 1 |
| Files: | 1,073 |
| Messages: | 98,006 |
Le Sun, Apr 20, 2025 at 11:22:04PM +0500, Andrey Rakhmatullin a Θcrit :
On Sun, Apr 20, 2025 at 06:25:53PM +0100, Josh Triplett wrote:
What I'm suggesting here is that if every individual package that needs
awk has a Depends on it (via a package that allows switching
implementations), rather than relying on Essential, then it becomes
possible to make incremental progress, and that incremental progress
benefits people who are willing to carefully remove some of what Debian
normally always has installed packages.
Should we start declaring deps on all essential packages explicitly?
There are maintainers scripts that run without the dependencies installed
(or even without the package being installed).
They can only use Essential:yes packages.
There is no place to write such dependency currently.
Having some mechanism to create package-specific users seems like one
useful goal, and I don't understand why each package has to write
scripts to invoke 'adduser' and deal with all the complexity around
that on their own.
Having some mechanism to create package-specific users seems like oneWe have one: it is documented in sysusers.d(5).
useful goal, and I don't understand why each package has to write
scripts to invoke 'adduser' and deal with all the complexity around that
on their own. There could be a declarative interface a package can use
and say 'USERS+=saned' or 'USERS+=munin' or 'USERS+=openldap' and that's
it.
On May 12, Simon Josefsson <simon@josefsson.org> wrote:
Having some mechanism to create package-specific users seems like one >>useful goal, and I don't understand why each package has to writeWe have one: it is documented in sysusers.d(5).
scripts to invoke 'adduser' and deal with all the complexity around that
on their own. There could be a declarative interface a package can use
and say 'USERS+=saned' or 'USERS+=munin' or 'USERS+=openldap' and that's >>it.
Now you just need to persuade everybody to use it.
Marco d'Itri <md@Linux.IT> writes:
On May 12, Simon Josefsson <simon@josefsson.org> wrote:
Having some mechanism to create package-specific users seems like oneWe have one: it is documented in sysusers.d(5).
useful goal, and I don't understand why each package has to write
scripts to invoke 'adduser' and deal with all the complexity around that >>> on their own. There could be a declarative interface a package can use
and say 'USERS+=saned' or 'USERS+=munin' or 'USERS+=openldap' and that's >>> it.
Now you just need to persuade everybody to use it.
Oh I wasn't aware of that, thanks for the pointer. Is there any known
reason (except lack of time) that people aren't using it? I'll see if I
can come up with a way to use it in some packages, I think 'pqconnect'
would be a good candidate -- the postinst script is only there to call addgroup+adduser and it always felt like a hack.
https://salsa.debian.org/python-team/packages/pqconnect/-/issues/13
Marco d'Itri <md@Linux.IT> writes:
On May 12, Simon Josefsson <simon@josefsson.org> wrote:
Having some mechanism to create package-specific users seems like one useful goal, and I don't understand why each package has to write
scripts to invoke 'adduser' and deal with all the complexity around that on their own. There could be a declarative interface a package can use and say 'USERS+=saned' or 'USERS+=munin' or 'USERS+=openldap' and that's it.
We have one: it is documented in sysusers.d(5).
Now you just need to persuade everybody to use it.
Oh I wasn't aware of that, thanks for the pointer. Is there any known
reason (except lack of time) that people aren't using it? I'll see if I
can come up with a way to use it in some packages, I think 'pqconnect'
would be a good candidate -- the postinst script is only there to call addgroup+adduser and it always felt like a hack.
https://salsa.debian.org/python-team/packages/pqconnect/-/issues/13
Relatively new perhaps. Needs a little fiddling to work with debhelper compat level 13 (needs dh helper called from d/rules).
Hi Ahmad,
Il 13 maggio 2025 00:30:09 CEST, Ahmad Khalifa <ahmad@khalifa.ws> ha scritto:
Relatively new perhaps. Needs a little fiddling to work with debhelper compat level 13 (needs dh helper called from d/rules).
You might want to build-depend on dh-sequence-sysusers instead. This way, you don't need to fiddle with d/rules.
Are there any guarantees on semantics for package removals? Will the user/group be removed from /etc/{passwd,group} or not? Will it remove
the home directory? What happens if the home directory is not empty?
Will it remove files owned by that user/group elsewhere? I recall
different packages have different preferences on these topics.
On Wed, May 14, 2025 at 09:30:25AM +0200, Simon Josefsson wrote:
Are there any guarantees on semantics for package removals? Will the
user/group be removed from /etc/{passwd,group} or not? Will it remove
the home directory? What happens if the home directory is not empty?
Will it remove files owned by that user/group elsewhere? I recall
different packages have different preferences on these topics.
see #228692 from 20024, or maybe directly jump to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228692#63
from at least 2020.
To quote Russ once again: 'I think Policy should say something like
"created users and groups should not be removed by default, but may be removed on purge if the local administrator explicitly requests this, either for that package or as a system-wide default."
I think this is still the best practice, even if underdocumented.
Finally I'd like to add that I would not remove home directories even on purge, unless they are empty.
systemd's sysuser support is only apparently slightly better thanThis is much less of an issue that it used to be, because nowadays the /{etc,run,var/*}/$NAME directories can be created most of the times on
adduser (in that it is declarative), otherwise it feels rather
underwhelming in the package management context. It does not solve being
able to use such users in .deb files w/o maintainer scripts, it currently
also uses maintainer scripts for its normal operation (you just do notI suppose that you could implement support for calling systemd-sysusers directly in dpkg, if you think it is needed.
write them explicitly),
it does not solve bootstrapping issues, doesWhat do you mean here?
not support setting a system-wide policy on whether to remove the >users/groups on package purge, etc.I think that this could be implemented in systemd-sysusers, if somebody
To quote Russ once again: 'I think Policy should say something like
"created users and groups should not be removed by default, but may be >removed on purge if the local administrator explicitly requests this, either >for that package or as a system-wide default."
I think this is still the best practice, even if underdocumented.