On Wed, 22 Mar 2006 17:31:28 +0100, Christian.Iseli@xxxxxxxx wrote:
> > Without overriding shadow-utils from the outside, you cannot replace it or
> > change its behaviour. Without modifying the dependency chain, you cannot
> > influence installation-order either. Hence there's no way to insert a
> > configuration package into the depchain.
>
> Ok.
>
> > Technically, packages which run "useradd" require /usr/sbin/useradd in Fedora
> > space. They don't require an arbitrary "useradd" in $PATH. They don't require
> > a package with the name "shadow-utils". And no other package (not in Core and
> > not in Extras either) must replace or otherwise conflict with /usr/sbin/
> > useradd unless it is given a different file name.
>
> But something similar is done for e.g. /usr/sbin/sendmail , which is a symlink
> to /etc/alternatives/mta , which offers a way to replace the original sendmail
> with a customized one
At run-time, not at install-time. *boom*
[For competing packages, which provide the same base functionality,
"alternatives" may be seen as sufficient. Although, there's the risk that
program A and program B are not completely interchangeable. That's
admittedly ugly.]
Transfer this scenario from Core ("sendmail" package) to Core
("shadow-utils" package) plus an Extras package, which the admin must
configure at install-time to adjust its install-time behaviour (i.e.
choose the base uid) for the remaining packages to be installed. Do you
see the problem? Good. Go a step farther and move the Extras into Core? Do
you still see the problem? ==> Competing packages -- and every pair of
packages which provides the same virtual capabilities competes with
eachother at the depsolver level -- must be interchangeable. shadow-utils
and an alternative [modified] implementation in a different package are
not interchangeable if install-time configuration is desired.
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
