On Mar 6, 2011, at 12:26 PM, Per Øyvind Karlsen wrote:
> using right address this time..
>
> 2011/3/6 Per Øyvind Karlsen <peroyv...@mandriva.org>:
>> 2011/3/6 Jeff Johnson <n3...@mac.com>:
>>>
>>> On Mar 6, 2011, at 9:42 AM, Jeff Johnson wrote:
>>>
>>>> Under #ifdef RPM_VENDOR_MANDRIVA please.
>>>>
>>>> The problem you are trying to solve is with aliasing
>>>> for a package identifier, which sometimes has
>>>> Distepoch: and sometimes does not?
>>>>
>>>> If so the patch is mostly in the right place, but a "real"
>>>> solution will be to decide on convention(s) for
>>>> RPMTAG_NAME this is used solely for identification
>>>> RPMTAG_PROVIDENAME this is used solely for assertions
>>>> What is confusing is that those two usage cases have exactly the same
>>>> string
>>>> values, and adding Distepoch: has confused matters a bit (not in an
>>>> important way).
>>>>
>>>> The convention(s) (that need to be finalized) are implemented
>>>> when RPMTAG_PROVIDENAME is added to a header, not here, where
>>>> you are essentially substituting one alias for the other
>>>> where the real need (imho) is to split "identification" <-> "assertion"
>>>> name spaces cleanly.
>>>>
>>>> Gud enuf for now, and until there's clarity on Distepoch: conventions.
>>>>
>>>
>>> Let me underscore what I think needs to be decided.
>>>
>>> Distepoch: (and Disttag:) are adding "branding" identifiers. That's
>>> fine for identification purposes.
>>>
>>> WHat hasn't been decided is this:
>>> Do you want "branding" throughout assertions too?
>>>
>>> i.e. should Distepoch: be added to all dependencies as well as to {N,E,V,R}.
>> I prefer for it to be added in same fashion as epoch, it being the least
>> significant value, omitting it for provides only using %{version}-%{release}
>> provides EVR will then be okay as well if one wants.
This isn't *too* surprising, but Epoch: has an important semantic
attached and is absolutely neded. There is less of a need
(or Distepoch: would have been added years ago to RPM) with
Disttag: or Distepoch: other than "identification" and "branding".
There's no possible way that, say,
Always prefer mdv2011.0 over 2010.2.
can be mapped into dependency assertions. You plain and simply can't
afford the necessary QA and are doomed to "dependency hell" if
you even try to do that.
See arekm's request for
How do I replace all i[3456]86 with x86_64 packages?
arch is no different than the "mdv2011" Distepoch: marker.
And RPM and all depsolvers based on rpmlib just aren't prepared for
the two rule-based "policies" I've just stated (even if the policies
are quite easy to express as a rule).
BTW: Your simplest possible approach w Distepoch: into dependencies
is still gonna be concatenation into the Release: string imho. Actually
adding a new element to the {E,V,R} tuple including a fully distinguished
D as separate tag everywhere will take some time to adjust and accept.
Surely you have seen this personally or you would not be checking
in patches like what started this thread.
>>
>> I at least personally prefer this logic to be mostly consistent with the
>> rest,
>> and also easiest to grasp and packagers to customize.
>>>
>>> Th benefit of adding is that RPM then continues with identically valued
>>> strings for WYSIWYG meeting package monkey expectations.
>>>
>>> The cost(s) of adding "branding" like Distepoch: to assertions are:
>>> 1) all package dependencies written in *.spec will need to be changed.
>>> 2) depsolver metadata is gonna increase in size with lots and lots of
>>> redundant "branding" strings.
>> Mostly just adding it to package NEVR only is sufficient for achieving both
>> main goals of "identification" and "upgrade".
The contexts of "identification" and "assertion" are different even if you
choose to claim "both".
>> Leaving it to packagers to add it to EVR of other provides as they see
>> fit seems sensible enough to me at least. :)
You haven't been -- but are likely about to be -- clubbed with bananas
from a horde of angry package monkeys. Been there, done that, here.
Meanwhile, the whole idea that thousands of *.spec files can be adjusted
in finite time by humans accurately and reliably is the RPM design flaw.
Try automation in rpmbuild. There's really no reason to rile up the package
monkeys
that I can see with Distepoch: ... ymmv.
>>>
>>> There's no reason a priori why RPMTAG_PROVIDENAME MUST include Distepoch:
>>> except
>>> to conform with expectations. Maybe I should encode all dependency strings
>>> in EBCDIC
>>> to prove that point ;-)
>>>
>>> Either approach is fine. But atm its all kinda muddled and ad hoc and in
>>> need of clarity.
I should point out my prefernce here too:
I think Distepoch: "branding" added throughout dependency assertions
will
further isolate Mandriva packaging from other distros.
That might well be the Chauvinist (and somewhat l33t) intent. I do not know ...
... but I do know that I can take, say, gzip from most any modern linux
distro and use rpm2cpio to achieve a functioning executable no matter
what markup has been added to the cellophane of packaging.
73 de Jeff______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
