On Tue, 11 Sep 2012, Jeffrey Johnson wrote:
> On Sep 11, 2012, at 6:58 AM, Jan Rękorajski <bagg...@pld-linux.org> wrote:
>
> >>
> >> $ rpm -q rpm
> >> rpm-5.4.10-0.12.x86_64
> >
> > The problem comes from mpd and stunnel have Provides user(%{name}) and
> > group(%{name}), and rpm mixes RPMNS_TYPE_USER/RPMNS_TYPE_GROUP namespace
> > deps with RPMNS_TYPE_VERSION(?) causing P:group(%{name}) to behave like
> > unversioned P:%{name} and satisfying that conflict:
> >
> > D: NO A config(mpd) = 0:0.16.7-4 B mpd < 0.16.5-4
> > D: YES A group(mpd) B mpd < 0.16.5-4
^^^^^^^^^^^^^^
> > D: Conflicts: mpd < 0.16.5-4 YES (db
> > provides)
^^^^^^^^^^^^^^^^^^^^^^^
> > D: package systemd-187-4.x86_64 has unsatisfied Conflicts: mpd < 0.16.5-4
> >
>
> There is a namespace collision for user(…) and group(…).
>
> As implemented @rpm5.org, the user(…) and group(…) namespaces
> have a pre-defined semantic and are satisfied by lookup up
> the user/group using getpwent(3) getgrent(3).
>
> Specifically, "run-time probes" are _NOT_ satisfied by
> examining package Provides:, but by looking up strings
> using the usual glibc name services.
>
> (aside)
> At some point the implementation will be extended so that
> Provides: user(foo) = N
> will add an entry to /etc/passwd (where N = the desired uid),
> withe removal mapped to an Obsoletes:
What abous stuff like homedir, gecos, supplementary groups, etc.?
> > Shouldn't rpmdsCompare test if the comparison is in the same namespace?
> >
>
> rpmdsCompare() already SHOULD have this behavior: the routine
> won't be called for user(…) and group(…) name spaces.
As you can see above it is called with 'mpd < 0.16.5-4' dep from
installed package (this is the code path that skips NSType user/group)
and 'config(mpd) = 0:0.16.7-4' and 'group(mpd)' from db iteration which
have no NSType checking.
> (aside)
> BTW, it would have been far easier if you had chosen
> to discuss issues before upgrading to rpm-5.4.x.
Unfortunately the only problems that I was aware of was some 3y old
segfaults :(
> Reactively re-vetting incompatibilities as discovered
> is in noone's interest because of the tyranny of
> Upgrades MUST "work".
> because all that will, happen is PLD will rip out every
> implementation that has been accomplished over the past
> few years to achieve
> Have it your own way!
> which is indistinguishable from a "fork".
Currently the only incompatibility is P:user()/group() we're talking
about here. And it looks to me like unchecked code path issue we
can fix and be both happy.
Believe me I don't want to introduce incompatibilities as those will
make my life harder later on maintaining them.
> I personally have little interest in re-visiting
> what is now ancient (>3y ago) hysteria.
>
> I have offered repeatedly to assist PLD upgrades and
> both arekm/glen SHOUL be aware of all of the changes,
> and have had an opportunity to discuss incompatibilities
> and rationales when these changes were made years ago.
--
Jan Rękorajski | PLD/Linux
SysAdm | http://www.pld-linux.org/
baggins<at>mimuw.edu.pl
baggins<at>pld-linux.org
_______________________________________________
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
