Re: rpm 5.4.10 for testing in th-test
On Tue, Sep 11, 2012 at 11:06:45PM -0400, Jeffrey Johnson wrote:
> There's no well defined semantic for
> Provides: group(mpd)
> even if PLD has adopted some convention afaik. The
> Provides: group(mpd)
> is just a string and (imho) should be removed
> if there are problems unless there is truly some
> explicit PLD implementation that relies on the adopted
> convention.
There is.
PLD. Packages with 'Provides: group(mpd)' call the '%groupadd' macro
during installation, which creates the group if it is not already
defined. When uninstalled they call the '%groupremove' macro.
The same 'group(mpd)' may be provided by multiple packages (probably not
much sense with the 'mpd' group, but important for other cases) and the
group will be removed only when the last package which provides it is
removed. So the 'Provides: user(*)' and 'Provides: group(*)' are
critical for our %{user,group}{add,remove} macros.
Other solutions to the problem (multiple packages using the same
user/groups) would be:
- including every system uid/gid in the 'setup' package.
Disadvantages: lots of unneeded user and groups defined on every PLD
system and the need to update the setup package whenever user/group is
needed for anything else.
- providing each such user/group/user&group via a single packages
Disadvantages: some packages would be created only to hold a single
user or group definition.
- never removing users/groups added
Disadvantages: mess left after uninstalled packages
Our useradd/groupadd macros with 'Provides: user/group(*)' seem to be
quite an elegant solution in comparison and RPM 5.x still doesn't seem
to provide anything better.
Greets,
Jacek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm 5.4.10 for testing in th-test
On Tue, 11 Sep 2012, Jeffrey Johnson wrote: > > On Sep 11, 2012, at 5:22 PM, Jan Rękorajski wrote: > > >> > >> Any idea why the code above isn't being traversed? I'm > >> missing something here, any help appreciated. > > > > dep in question is of the TYPE_VERSION here, comes from package being > > installed and it is 'mpd < 0.16.5-4' > > 'group(mpd)' comes from the rpmdb Provides iteration later on. > > > > Because I lack specifics, I need clarification: > > Is the > Provides: group(mpd) > retrieved from Providename index in rpmdb matching a > Conflicts: mpd < 0.16.5-4 > from a package header in the code you posted? > > That's broken imho (and I should have enough details > to find the flaw if/when you confirm). Yes, this is exactly what is happening. IMHO rpmdsCompare needs a test (A->ns.Type == B->ns.Type), but I dont't know if it won't cause side-effects. -- Jan Rękorajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: texlive 2012
The reason of splitting: texlive is arch-dependent, texlive-texmf is arch-independent. The versions are different. > - texlive-texmf.spec: texlive-latex-bibtex-data > - texlive.spec: texlive-latex-bibtex - it requires the above, but you have > to build texlive.spec first You can build texlive.spec with older texlive-latex-bibtex-data. This is the reason why need bootstrap. So you'll build texlive2012 with texlive-texmf2008, after you'll build texlive-texmf2012 with texlive2012, and rebuild texlive2012 with texlive-texmf2012. > I would suggest to merge those two specs again. Bit more painful > to build, but much simpler to maintain. I think the maintain isn't harder with two little(?) specs. I think it would be nice to create a policy: which type of files belongs to texlive and which belongs to texlive-texmf and apply this policy. Some time ago, when I've split texlive.spec to texlive.spec and texlive-texmf.spec many things was adhoc-style :) So first need a big-big cleaning and I think after this the maintain will be simple. With one big spec: the build will be hard, see above, as you wrote: you'll build the texlive.spec's texlive-bin and after you'll install these packages and build texlive.spec's texlive-texmf? Zsolt ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm 5.4.10 for testing in th-test
On Sep 11, 2012, at 5:22 PM, Jan Rękorajski wrote: >> >> Any idea why the code above isn't being traversed? I'm >> missing something here, any help appreciated. > > dep in question is of the TYPE_VERSION here, comes from package being > installed and it is 'mpd < 0.16.5-4' > 'group(mpd)' comes from the rpmdb Provides iteration later on. > Because I lack specifics, I need clarification: Is the Provides: group(mpd) retrieved from Providename index in rpmdb matching a Conflicts: mpd < 0.16.5-4 from a package header in the code you posted? That's broken imho (and I should have enough details to find the flaw if/when you confirm). (aside) The easy work around is removing Provides: group(md5) although I lack sufficient details on what is/was intended with that dependency to say for sure. Removing the Provides: SHOULD prevent the Conflicts: from firing. Post the details at launchpad.net/rpm and I'll sort the segfaults for you. >>> >>> I don't know if they're worth you attention, all of them seem outdated: >>> >>> - headerGet() making poldek segfault http://rpm5.org/cvs/tktview?tn=38,1 >>> - rpm doesn't exit when no sources/patches available >>> http://rpm5.org/cvs/tktview?tn=40,1 >>> - http://rpm5.org/cvs/tktview?tn=41&_submit=Show >>> - when adopting, use 4.5 ticket for checklist: >>> https://bugs.launchpad.net/pld-linux/+bug/262985 >>> >> >> I will look later tonight (to ensure actually fixed). > > Thanks in advance :) > >> 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. > Hard to say what happy means from here without knowing what is being proposed. But yes, an accidental name collision can be sorted without pain. The hardest issue is What about "legacy compatibility" with versions of RPM that do not have "run-time probes"? The better approach is back porting, but otherwise "run-time probes" are merely serialized strings that can be stubbed out in older versions of rpm without too much difficulty. >>> >>> AFAIK, even our rpm 4.5 has "run-time probes" like uname(release), >>> so they're not the problem here. I can live with some level of legacy >>> breakage, one have to cut off the long tail sometime. >>> >> >> Good (I've mostly forgotten whether probes are in rpm-4.5 these days). >> >> But if using "run-time probes", then I'm not sure why >> there are >> Provides: user(mpd) … >> dependencies being added. Or am I confused somehow? > > Hmm, besides not being able to find that particular probe in rpm5 > source (may be me tired), how can we tell that _this_ package provide > _that_ username other than specyfying Provides: user(mpd)? > The confusion is likely that I wasn't sure whether it was a user(…) or a group(…) dependency which are quite similar in form. Perhaps I should have said Provides: group(mpd) > I always considered user() and group() provides as a means to tell that > those user/group names come from the package having appriopriate Provides. > There's no well defined semantic for Provides: group(mpd) even if PLD has adopted some convention afaik. The Provides: group(mpd) is just a string and (imho) should be removed if there are problems unless there is truly some explicit PLD implementation that relies on the adopted convention. (aside) The future intent @rpm5.org is to overload Provides:/Obsoletes: as a means to automate adding/deleting entries in /etc/passwd and /etc/group (where there will be an explicit semantic attached to the namespace(s). The only show stopping issue is committing to a tuple serialization that maps onto the necessary fields needed in /etc/passwd etc with reasonable defaults for missing values. Consensus on representations in *.spec is always rate limiting: it literally takes years before the complaints from package monkeys disappear, sigh. hth 73 de Jeff > -- > Jan Rękorajski | PLD/Linux > SysAdm | http://www.pld-linux.org/ > bagginsmimuw.edu.pl > bagginspld-linux.org > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm 5.4.10 for testing in th-test
On Tue, 11 Sep 2012, Jeffrey Johnson wrote:
>
> On Sep 11, 2012, at 4:49 PM, Jan Rękorajski wrote:
>
> >>
> >
> > No, it's this piece of code in rpmlib lib/depends.c:~1450:
> >
>
> Got it …
>
> >mi = rpmtsInitIterator(ts, RPMTAG_PROVIDENAME, Name, 0);
> >(void) rpmmiPrune(mi,
> >ts->removedPackages, ts->numRemovedPackages, 1);
> >while ((h = rpmmiNext(mi)) != NULL) {
> >if (rpmdsAnyMatchesDep(h, dep, _rpmds_nopromote)) {
> >rpmdsNotify(dep, _("(db provides)"), rc);
> >mi = rpmmiFree(mi);
> >goto exit;
> >}
> >}
> >mi = rpmmiFree(mi);
> >
> > dep here is 'mpd < 0.16.5-4', and it goes through all NSType checks,
> > h becomes 'group(mpd)' and is never tested if its NSType matches the dep
> > it is compared to.
> >
>
> … that code should not have been traversed.
>
> I'm expecting this code in lib/depends.c:955 to catch user(…) and group(…):
>
> /* Evaluate user/group lookup probes. */
> if (NSType == RPMNS_TYPE_USER) {
> const char *s;
> uid_t uid = 0;
> s = Name; while (*s && xisdigit(*s)) s++;
>
> if (*s)
> xx = unameToUid(Name, &uid);
> else {
> uid = strtol(Name, NULL, 10);
> xx = (uidToUname(uid) ? 0 : -1);
> }
> rc = (xx >= 0 ? 0 : 1);
> if (Flags & RPMSENSE_MISSINGOK)
> goto unsatisfied;
> rpmdsNotify(dep, _("(user lookup)"), rc);
> goto exit;
> }
> if (NSType == RPMNS_TYPE_GROUP) {
> const char *s;
> gid_t gid = 0;
> s = Name; while (*s && xisdigit(*s)) s++;
>
> if (*s)
> xx = gnameToGid(Name, &gid);
> else {
> gid = strtol(Name, NULL, 10);
> xx = (gidToGname(gid) ? 0 : -1);
> }
> rc = (xx >= 0 ? 0 : 1);
> if (Flags & RPMSENSE_MISSINGOK)
> goto unsatisfied;
> rpmdsNotify(dep, _("(group lookup)"), rc);
> goto exit;
> }
>
> Any idea why the code above isn't being traversed? I'm
> missing something here, any help appreciated.
dep in question is of the TYPE_VERSION here, comes from package being
installed and it is 'mpd < 0.16.5-4'
'group(mpd)' comes from the rpmdb Provides iteration later on.
> >> Post the details at launchpad.net/rpm and I'll sort
> >> the segfaults for you.
> >
> > I don't know if they're worth you attention, all of them seem outdated:
> >
> > - headerGet() making poldek segfault http://rpm5.org/cvs/tktview?tn=38,1
> > - rpm doesn't exit when no sources/patches available
> > http://rpm5.org/cvs/tktview?tn=40,1
> > - http://rpm5.org/cvs/tktview?tn=41&_submit=Show
> > - when adopting, use 4.5 ticket for checklist:
> > https://bugs.launchpad.net/pld-linux/+bug/262985
> >
>
> I will look later tonight (to ensure actually fixed).
Thanks in advance :)
> 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.
> >>>
> >>
> >> Hard to say what happy means from here without knowing
> >> what is being proposed. But yes, an accidental name collision
> >> can be sorted without pain. The hardest issue is
> >>What about "legacy compatibility" with versions
> >>of RPM that do not have "run-time probes"?
> >> The better approach is back porting, but otherwise
> >> "run-time probes" are merely serialized strings that can be stubbed
> >> out in older versions of rpm without too much difficulty.
> >
> > AFAIK, even our rpm 4.5 has "run-time probes" like uname(release),
> > so they're not the problem here. I can live with some level of legacy
> > breakage, one have to cut off the long tail sometime.
> >
>
> Good (I've mostly forgotten whether probes are in rpm-4.5 these days).
>
> But if using "run-time probes", then I'm not sure why
> there are
> Provides: user(mpd) …
> dependencies being added. Or am I confused somehow?
Hmm, besides not being able to find that particular probe in rpm5
source (may be me tired), how can we tell that _this_ package provide
_that_ username other than specyfying Provides: user(mpd)?
I always considered user() and group() provides as a means to tell that
those user/group names come from the package having appriopriate Provides.
--
Jan Rękorajski | PLD/Linux
SysAdm | http://www.pld-linux.org/
bagginsmimuw.edu.pl
bagginspld-linux.org
___
Re: rpm 5.4.10 for testing in th-test
On Sep 11, 2012, at 4:49 PM, Jan Rękorajski wrote:
>>
>
> No, it's this piece of code in rpmlib lib/depends.c:~1450:
>
Got it …
>mi = rpmtsInitIterator(ts, RPMTAG_PROVIDENAME, Name, 0);
>(void) rpmmiPrune(mi,
>ts->removedPackages, ts->numRemovedPackages, 1);
>while ((h = rpmmiNext(mi)) != NULL) {
>if (rpmdsAnyMatchesDep(h, dep, _rpmds_nopromote)) {
>rpmdsNotify(dep, _("(db provides)"), rc);
>mi = rpmmiFree(mi);
>goto exit;
>}
>}
>mi = rpmmiFree(mi);
>
> dep here is 'mpd < 0.16.5-4', and it goes through all NSType checks,
> h becomes 'group(mpd)' and is never tested if its NSType matches the dep
> it is compared to.
>
… that code should not have been traversed.
I'm expecting this code in lib/depends.c:955 to catch user(…) and group(…):
/* Evaluate user/group lookup probes. */
if (NSType == RPMNS_TYPE_USER) {
const char *s;
uid_t uid = 0;
s = Name; while (*s && xisdigit(*s)) s++;
if (*s)
xx = unameToUid(Name, &uid);
else {
uid = strtol(Name, NULL, 10);
xx = (uidToUname(uid) ? 0 : -1);
}
rc = (xx >= 0 ? 0 : 1);
if (Flags & RPMSENSE_MISSINGOK)
goto unsatisfied;
rpmdsNotify(dep, _("(user lookup)"), rc);
goto exit;
}
if (NSType == RPMNS_TYPE_GROUP) {
const char *s;
gid_t gid = 0;
s = Name; while (*s && xisdigit(*s)) s++;
if (*s)
xx = gnameToGid(Name, &gid);
else {
gid = strtol(Name, NULL, 10);
xx = (gidToGname(gid) ? 0 : -1);
}
rc = (xx >= 0 ? 0 : 1);
if (Flags & RPMSENSE_MISSINGOK)
goto unsatisfied;
rpmdsNotify(dep, _("(group lookup)"), rc);
goto exit;
}
Any idea why the code above isn't being traversed? I'm
missing something here, any help appreciated.
>> Then there is the further design decision to decide
>> how to interpret user(…) and group(…) wrappings
>> with poldek+rpm to maximize "legacy compatibility" and
>> minimize maintenance.
>>
(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 :(
>>>
>>
>> Post the details at launchpad.net/rpm and I'll sort
>> the segfaults for you.
>
> I don't know if they're worth you attention, all of them seem outdated:
>
> - headerGet() making poldek segfault http://rpm5.org/cvs/tktview?tn=38,1
> - rpm doesn't exit when no sources/patches available
> http://rpm5.org/cvs/tktview?tn=40,1
> - http://rpm5.org/cvs/tktview?tn=41&_submit=Show
> - when adopting, use 4.5 ticket for checklist:
> https://bugs.launchpad.net/pld-linux/+bug/262985
>
I will look later tonight (to ensure actually fixed).
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.
>>>
>>
>> Hard to say what happy means from here without knowing
>> what is being proposed. But yes, an accidental name collision
>> can be sorted without pain. The hardest issue is
>> What about "legacy compatibility" with versions
>> of RPM that do not have "run-time probes"?
>> The better approach is back porting, but otherwise
>> "run-time probes" are merely serialized strings that can be stubbed
>> out in older versions of rpm without too much difficulty.
>
> AFAIK, even our rpm 4.5 has "run-time probes" like uname(release),
> so they're not the problem here. I can live with some level of legacy
> breakage, one have to cut off the long tail sometime.
>
Good (I've mostly forgotten whether probes are in rpm-4.5 these days).
But if using "run-time probes", then I'm not sure why
there are
Provides: user(mpd) …
dependencies being added. Or am I confused somehow?
73 de Jeff
> --
> Jan Rękorajski | PLD/Linux
> SysAdm | http://www.pld-linux.org/
> bagginsmimuw.edu.pl
> bagginspld-linux.org
> __
> RPM Package Managerhttp://rpm5.org
> Developer Communication Listrpm-de...@rpm5.org
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: texlive 2012
Does it make sense to have texlive.spec and texlive-texmf.spec? I understand that the latter deals with much larger source file, but then we have to deal with problems like the following - amstex.1 manual is provided by texlive.spec - amstex format and other files are provided by texlive-texml.spec Also, due to two spec files we create some artificial packages, i.e. - texlive-texmf.spec: texlive-latex-bibtex-data - texlive.spec: texlive-latex-bibtex - it requires the above, but you have to build texlive.spec first I would suggest to merge those two specs again. Bit more painful to build, but much simpler to maintain. Regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm 5.4.10 for testing in th-test
On Tue, 11 Sep 2012, Jeffrey Johnson wrote:
>
> On Sep 11, 2012, at 2:29 PM, Jan Rękorajski wrote:
>
> > On Tue, 11 Sep 2012, Jeffrey Johnson wrote:
> >
> >> On Sep 11, 2012, at 6:58 AM, Jan Rękorajski 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: YESA group(mpd)B mpd < 0.16.5-4
> > ^^
> >>> D: Conflicts: mpd < 0.16.5-4YES (db
> >>> provides)
> >
> > ^^^
>
> Yes, already noted (but I do not know what patches
> you are applying).
Nothing special there, AFAIR.
> >>> D: package systemd-187-4.x86_64 has unsatisfied Conflicts: mpd < 0.16.5-4
> >>>
> >>
[...]
> >>> 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.
> >
>
> So its called from poldek, not from rpmlib lib/depends.c?
No, it's pure rpmlib lib/depends.c.
> Yes: you need to parse the user(…) and group(…) namespace
> wrappers similar to what is being done in unsatisfiedDepend()
> near lib/depends.c:868.
No, it's this piece of code in rpmlib lib/depends.c:~1450:
mi = rpmtsInitIterator(ts, RPMTAG_PROVIDENAME, Name, 0);
(void) rpmmiPrune(mi,
ts->removedPackages, ts->numRemovedPackages, 1);
while ((h = rpmmiNext(mi)) != NULL) {
if (rpmdsAnyMatchesDep(h, dep, _rpmds_nopromote)) {
rpmdsNotify(dep, _("(db provides)"), rc);
mi = rpmmiFree(mi);
goto exit;
}
}
mi = rpmmiFree(mi);
dep here is 'mpd < 0.16.5-4', and it goes through all NSType checks,
h becomes 'group(mpd)' and is never tested if its NSType matches the dep
it is compared to.
> Then there is the further design decision to decide
> how to interpret user(…) and group(…) wrappings
> with poldek+rpm to maximize "legacy compatibility" and
> minimize maintenance.
>
> >> (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 :(
> >
>
> Post the details at launchpad.net/rpm and I'll sort
> the segfaults for you.
I don't know if they're worth you attention, all of them seem outdated:
- headerGet() making poldek segfault http://rpm5.org/cvs/tktview?tn=38,1
- rpm doesn't exit when no sources/patches available
http://rpm5.org/cvs/tktview?tn=40,1
- http://rpm5.org/cvs/tktview?tn=41&_submit=Show
- when adopting, use 4.5 ticket for checklist:
https://bugs.launchpad.net/pld-linux/+bug/262985
> >> 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.
> >
>
> Hard to say what happy means from here without knowing
> what is being proposed. But yes, an accidental name collision
> can be sorted without pain. The hardest issue is
> What about "legacy compatibility" with versions
> of RPM that do not have "run-time probes"?
> The better approach is back porting, but otherwise
> "run-time probes" are merely serialized strings that can be stubbed
> out in older versions of rpm without too much difficulty.
AFAIK, even our rpm 4.5 has "run-time probes" like uname(release),
so they're not the problem here. I can live with some level of legacy
breakage, one have to cut off the long tail sometime.
--
Jan Rękorajski | PLD/Linux
SysAdm | http://www.pld-linux.org/
bagginsmimuw.edu.pl
bagginspld-linux.org
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm 5.4.10 for testing in th-test
On Tue, 11 Sep 2012, Jeffrey Johnson wrote:
> On Sep 11, 2012, at 6:58 AM, Jan Rękorajski 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: YESA group(mpd)B mpd < 0.16.5-4
^^
> > D: Conflicts: mpd < 0.16.5-4YES (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/
bagginsmimuw.edu.pl
bagginspld-linux.org
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm 5.4.10 for testing in th-test
On Sep 11, 2012, at 2:29 PM, Jan Rękorajski wrote:
> On Tue, 11 Sep 2012, Jeffrey Johnson wrote:
>
>> On Sep 11, 2012, at 6:58 AM, Jan Rękorajski 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: YESA group(mpd)B mpd < 0.16.5-4
> ^^
>>> D: Conflicts: mpd < 0.16.5-4YES (db
>>> provides)
>
> ^^^
Yes, already noted (but I do not know what patches
you are applying).
>>> 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.?
>
(aside)
Yes there is a tuple of information that needs to be
well defined. This is no harder than defining some character
like ':' to serialize the tuple.
The harder issue will be permitting white space in *.spec
parsing, where the feeble/naive parsing to next ',' or white
space that is currently being parsed will have to be improved.
None of this is rocket science. And this isn't the
time or place to discuss the best way to automate
passed/group management within overloading RPM
Provides: user(foo)
Obsoletes: group(bar)
syntax to add/delete user/group items.
>>> 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.
>
So its called from poldek, not from rpmlib lib/depends.c?
Yes: you need to parse the user(…) and group(…) namespace
wrappers similar to what is being done in unsatisfiedDepend()
near lib/depends.c:868.
Then there is the further design decision to decide
how to interpret user(…) and group(…) wrappings
with poldek+rpm to maximize "legacy compatibility" and
minimize maintenance.
>> (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 :(
>
Post the details at launchpad.net/rpm and I'll sort
the segfaults for you.
>> 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.
>
Hard to say what happy means from here without knowing
what is being proposed. But yes, an accidental name collision
can be sorted without pain. The hardest issue is
What about "legacy compatibility" with versions
of RPM that do not have "run-time probes"?
The better approach is back porting, but otherwise
"run-time probes" are merely serialized strings that can be stubbed
out in older versions of rpm without too much difficulty.
> Believe me I don't want to introduce incompatibilities as those will
> make my life harder later on maintaining them.
>
Good (neither do I).
73 de Jeff
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
git.pld <> github problem encountered
When doing slug.py init: Initialized empty Git repository in /cvs/root/gitolite/repositories/packages/telepathy-spec.git/ Cannot create repository telepathy-spec on github Problem with creating gihub mirror for packages/telepathy-spec at /home/services/git/adc/bin/create line 27. And when git pushing: remote: ssh_exchange_identification: Connection closed by remote host remote: fatal: The remote end hung up unexpectedly -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm 5.4.10 for testing in th-test
On Sep 11, 2012, at 6:58 AM, Jan Rękorajski 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: YESA group(mpd)B mpd < 0.16.5-4
> D: Conflicts: mpd < 0.16.5-4YES (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:
> 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.
(aside)
BTW, it would have been far easier if you had chosen
to discuss issues before upgrading to rpm-5.4.x.
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".
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.
hth
73 de Jeff
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm 5.4.10 for testing in th-test
On Tue, 11 Sep 2012, Jan Rękorajski wrote:
> On Tue, 11 Sep 2012, Elan Ruusamäe wrote:
>
> > On 11.09.2012 13:58, Jan Rękorajski wrote:
> > > On Tue, 11 Sep 2012, Artur Frysiak wrote:
> > >
> > >> On Tue, Sep 11, 2012 at 7:29 AM, Jan Rękorajski
> > >> wrote:
> > >>> On Mon, 10 Sep 2012, Artur Frysiak wrote:
> > $ LC_ALL=C sudo rpm -Uhv systemd-187-4.x86_64.rpm
> > systemd-libs-187-4.x86_64.rpm systemd-units-187-4.x86_64.rpm
> > udev-core-187-4.x86_64.rpm udev-libs-187-4.x86_64.rpm
> > udev-initrd-187-4.x86_64.rpm udev-187-4.x86_64.rpm
> > error: Failed dependencies:
> > mpd < 0.16.5-4 conflicts with systemd-187-4.x86_64
> > stunnel < 4.50-2 conflicts with systemd-187-4.x86_64
> > $ rpm -q mpd stunnel
> > mpd-0.16.7-4.x86_64
> > stunnel-4.52-1.x86_64
> > >>> rpm -q rpm? ;)
> > >> $ 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: YESA group(mpd)B mpd < 0.16.5-4
> > > D: Conflicts: mpd < 0.16.5-4YES (db
> > > provides)
> > > D: package systemd-187-4.x86_64 has unsatisfied Conflicts: mpd < 0.16.5-4
> > >
> > > Shouldn't rpmdsCompare test if the comparison is in the same namespace?
> > >
> >
> > this part was disabled in rpm 4.5, seems the patch is not working or
> > gone missing?
> > patch should have link to bugtracker where previous problems were described
>
> rpm behaviour is the same with or without the patch.
> Probably it must touch something else, maybe name extraction from
> NAMESPACE(name)?
Ga, I seem to have broken the patch while updating to rpm5.
rel 0.13 will be fixed.
--
Jan Rękorajski | PLD/Linux
SysAdm | http://www.pld-linux.org/
bagginsmimuw.edu.pl
bagginspld-linux.org
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm 5.4.10 for testing in th-test
On Tue, 11 Sep 2012, Elan Ruusamäe wrote:
> On 11.09.2012 13:58, Jan Rękorajski wrote:
> > On Tue, 11 Sep 2012, Artur Frysiak wrote:
> >
> >> On Tue, Sep 11, 2012 at 7:29 AM, Jan Rękorajski
> >> wrote:
> >>> On Mon, 10 Sep 2012, Artur Frysiak wrote:
> $ LC_ALL=C sudo rpm -Uhv systemd-187-4.x86_64.rpm
> systemd-libs-187-4.x86_64.rpm systemd-units-187-4.x86_64.rpm
> udev-core-187-4.x86_64.rpm udev-libs-187-4.x86_64.rpm
> udev-initrd-187-4.x86_64.rpm udev-187-4.x86_64.rpm
> error: Failed dependencies:
> mpd < 0.16.5-4 conflicts with systemd-187-4.x86_64
> stunnel < 4.50-2 conflicts with systemd-187-4.x86_64
> $ rpm -q mpd stunnel
> mpd-0.16.7-4.x86_64
> stunnel-4.52-1.x86_64
> >>> rpm -q rpm? ;)
> >> $ 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: YESA group(mpd)B mpd < 0.16.5-4
> > D: Conflicts: mpd < 0.16.5-4YES (db
> > provides)
> > D: package systemd-187-4.x86_64 has unsatisfied Conflicts: mpd < 0.16.5-4
> >
> > Shouldn't rpmdsCompare test if the comparison is in the same namespace?
> >
>
> this part was disabled in rpm 4.5, seems the patch is not working or
> gone missing?
> patch should have link to bugtracker where previous problems were described
rpm behaviour is the same with or without the patch.
Probably it must touch something else, maybe name extraction from
NAMESPACE(name)?
--
Jan Rękorajski | PLD/Linux
SysAdm | http://www.pld-linux.org/
bagginsmimuw.edu.pl
bagginspld-linux.org
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm 5.4.10 for testing in th-test
On 11.09.2012 13:58, Jan Rękorajski wrote:
On Tue, 11 Sep 2012, Artur Frysiak wrote:
On Tue, Sep 11, 2012 at 7:29 AM, Jan Rękorajski wrote:
On Mon, 10 Sep 2012, Artur Frysiak wrote:
$ LC_ALL=C sudo rpm -Uhv systemd-187-4.x86_64.rpm
systemd-libs-187-4.x86_64.rpm systemd-units-187-4.x86_64.rpm
udev-core-187-4.x86_64.rpm udev-libs-187-4.x86_64.rpm
udev-initrd-187-4.x86_64.rpm udev-187-4.x86_64.rpm
error: Failed dependencies:
mpd < 0.16.5-4 conflicts with systemd-187-4.x86_64
stunnel < 4.50-2 conflicts with systemd-187-4.x86_64
$ rpm -q mpd stunnel
mpd-0.16.7-4.x86_64
stunnel-4.52-1.x86_64
rpm -q rpm? ;)
$ 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: YESA group(mpd)B mpd < 0.16.5-4
D: Conflicts: mpd < 0.16.5-4YES (db provides)
D: package systemd-187-4.x86_64 has unsatisfied Conflicts: mpd < 0.16.5-4
Shouldn't rpmdsCompare test if the comparison is in the same namespace?
this part was disabled in rpm 4.5, seems the patch is not working or
gone missing?
patch should have link to bugtracker where previous problems were described
in short: disable rpm behaviour, as we fill it P-s ourself
--
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm 5.4.10 for testing in th-test
On Tue, 11 Sep 2012, Artur Frysiak wrote:
> On Tue, Sep 11, 2012 at 7:29 AM, Jan Rękorajski wrote:
> > On Mon, 10 Sep 2012, Artur Frysiak wrote:
> >> $ LC_ALL=C sudo rpm -Uhv systemd-187-4.x86_64.rpm
> >> systemd-libs-187-4.x86_64.rpm systemd-units-187-4.x86_64.rpm
> >> udev-core-187-4.x86_64.rpm udev-libs-187-4.x86_64.rpm
> >> udev-initrd-187-4.x86_64.rpm udev-187-4.x86_64.rpm
> >> error: Failed dependencies:
> >> mpd < 0.16.5-4 conflicts with systemd-187-4.x86_64
> >> stunnel < 4.50-2 conflicts with systemd-187-4.x86_64
> >> $ rpm -q mpd stunnel
> >> mpd-0.16.7-4.x86_64
> >> stunnel-4.52-1.x86_64
> >
> > rpm -q rpm? ;)
>
> $ 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: YESA group(mpd)B mpd < 0.16.5-4
D: Conflicts: mpd < 0.16.5-4YES (db provides)
D: package systemd-187-4.x86_64 has unsatisfied Conflicts: mpd < 0.16.5-4
Shouldn't rpmdsCompare test if the comparison is in the same namespace?
--
Jan Rękorajski | PLD/Linux
SysAdm | http://www.pld-linux.org/
bagginsmimuw.edu.pl
bagginspld-linux.org
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
