[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: adduser Pre-Depends for qemu-system-common

I'm not an admin but I'm interested in ADDUSER breakage, if any.

Could you side-band me (reply to sender please) why adduser may have any (new) dependancy problems with adduser ? Obviously hacks that break adduser imply breakage to other softwares in or not in debian, which "supposedly against policy" (as if they follow that anymore).

There are so many hacks and additions to basic standards from dvd (series of image: now gone wild with hw incompatibility and changes) to user permissions bits (and what format) to just adding a user: it's crazy anything old OR new even works :) Why can't they build on things instead of break them - like they more or less used to do ?

For example I have a nice install time script that imports old password and group to be new password and group (it makes all changes needed, ie to filesystem too) so that new distribution has no problems in it's expectations while installing. adduser is employed somewhere within for obvious reasons.

Thank you,

	John Hendrickson

Ian Jackson wrote:
Wookey writes ("Re: adduser Pre-Depends for qemu-system-common"):
I don't know if there is a better way in this particular case but I do
know that adding users in preinsts does cause problems. Preinsts that
do anything important (which is not dealing with upgrades from
previous packages) cause issues for cross-arch rootfs generation,
where the system has to be booted before preinsts can be run. [...]

Making sure that the user/group is _also_ created in the postinst if
it's not already been done would make everything work nicely from my
POV. Avoiding doing such things in preinsts at all is good if possible. .

Perhaps a discussion of this issue would be welcome in the policy
manual ?


Reply to: