RPM Community Forums

Mailing List Message of <rpm-devel>

Re: distepoch problem with latest snapshot of 5.2

From: Jeff Johnson <n3npq@mac.com>
Date: Wed 26 Jan 2011 - 16:36:22 CET
Message-id: <5BE09F9A-C5BE-45FC-A6A7-785D56ECDA13@mac.com>

On Jan 26, 2011, at 4:15 AM, Anders F Björklund wrote:

> Matthew Dawkins wrote:
>>> I recently updated my snapshot of 5.2 to build around a perl upgrade to 5.12.2, but I didn't expect any problems really.
>>> Well pkgs that have requires like the following:
>>> Provides:   libpq = %{version}-%{release}
>>> now also have this half distepoch after it :2011.1
>>> made with a newer rpm5.2 snapshot
>>> rpm -qp --provides lib64pq8.4_5-8.4.5-3-
>>> unity2011.0.x86_64.rpm 
>>> postgresql-libs = 8.4.5-3
>>> libpq = 8.4.5-3
>>> lib64pq8.4_5-virtual = 8.4
>>> libpq.so.5()(64bit)
>>> lib64pq8.4_5 = 8.4.5-3:2011.0
>>> made with the older rpm5.2 snapshot
>>> rpm -qp --provides lib64pq8.4_5-8.4.4-3-unity2010.x86_64.rpm 
>>> postgresql-libs = 8.4.4-3
>>> libpq = 8.4.4-3
>>> lib64pq8.4_5-virtual = 8.4
>>> libpq.so.5()(64bit)
>>> lib64pq8.4_5 = 8.4.4-3
> This output looks different from what is initially described...
> i.e. the "Provides:   libpq = %{version}-%{release}" are the same,
> or at least not having a distepoch appended to the version-release
> The difference is instead the implicit provides ("lib64pq8.4_5")
>> Unity != Mandriva
>> The problem for Unity was that smart doesn't support it, nor does createrepo (i'm guessing)
> Originally there was one problem with rpm version display (in smart),
> which expanded into one markup issue with createrepo (and thus yum):
> The rpm versions were showing up without the "-%{disttag}%{distepoch}".
> Adding that (where present) to the RPM Loader, made the packages not
> match the ones in the Metadata Loader - and each would show up twice.
> Thus a createrepo patch was made to add <rpm:disttag>/<rpm:distepoch>.
> For the issue above, smart would also need to append a ":%{distepoch}"
> suffix to the version of the NameProvides created for each package.
> There was also a (minor) issue about distepochs not being properly
> split from version, so that they would end up in R rather than in D.

Pretty soon now, there needs to be a "choice" between ":foo" and "-foo"
to separate added fields. Otherwise we're all doomed to stare at spewage
for the next couple of years.

I personally believe that '-' is the better choice because its
already a forbidden character used for splitting EVR dependency tuples,
and is already de facto imposed by %mkrel appending Distag: and Distepoch:

There plain and simply is no justficiation for Yet More Aesthetic Spewage Markup
that I will ever understand.

Meanwhile SOME convention for disttag/distepoch patrsing is better than
	Have it your own way!
well duh!.

> I don't think either issue is tracked at https://launchpad.net/smart
> But all code is done, possibly lacking some on/off opt-out config...


> Don't really see any rpm issues here, other than adding more ways
> to "have it your own way" and I still don't know what the distepoch
> is useful for since I'm not using it myself (wrong vendor/packages).
> So problems are similar to the other ones with suggests/recommends.

Distepich: is no better or worse than any other identification/branding scheme.

But %mkrel implemented as a "parameterized macro" with its 3-4 layers
of nested macros is too fragile/feeble a form of macro madness imho.

And a specific tag in metadata, with a known semantic, and explictly
enumerable values, is sounder engineering than appending more clutter
to Release: fields. Note that you can append to RPMTAG_RELEASE with
whatever semiotic markers you wish for whatever purpose you want to
be parsed by whatever tools you choose forevermore. That is indeed
	Have it your own way!
in action.

> Or well I know what %{?dist} and %mkrel are being used for, and how
> Distepoch cleans up the Release field. I just don't know how useful
> it is to be able to compare package versions between OS releases ?
> Or if any gain outweighs the loss of the incompatibility introduced.

If done correctly and carefully, there is _NO_ incompatibility introduced
by Distepoch: or by Distag: or Repotag: or ... appended to Release: strings.

strings == strings

Everything else intended for identification/branding purposes has nothing
to do with Distepoch: or %{?distag} or ...

Thanks for comments. You are still as sane as ever ;-)

73 de Jeff
Received on Wed Jan 26 16:36:52 2011
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.