RPM Community Forums

Mailing List Message of <rpm-devel>

Re: new DISTEPOCH tag and cleaning of RELEASE tag polution

From: Per Øyvind Karlsen <pkarlsen@rpm5.org>
Date: Mon 22 Dec 2008 - 16:21:16 CET
Message-ID: <534660c60812220721ide4d501x474bbfdcd5cb6b16@mail.gmail.com>
2008/12/20 Jeff Johnson <n3npq@mac.com>

> Quoting
> "Br'er Fox, please don't throw me in the briar patch!", sez Br'er Rabbit.
> [1]
> Adding another structural field to package identifiers everywhere
> just adds complexity for no important gain imho.
> The lossages with DISTTAG (and REPOTAG and no DISTEPOCH} are perhaps easier
> (for me) to point out then the gains for an idea that I don't believe in.
> Here's a couple of points, you can certainly do whatever you wish:
> 1) ATM, rpm <-> dpkg tags can potentially be unified; both dpkg
> and rpm use a {E,V,R} triple for both package names and
> dependencies. Adding other elements structurally to the triple (as
> your patch does) will just make it harder to attempt unification.
> (not that anyone cares much anymore about rpm <-> dpkg unification).
> 2) Is there really any usefulness in suffixing, say, "mdv.2009.1" to every
> package (and to many, perhaps the majority, of package dependencies)
> contained in a distro release? The utility gain that is usually reported
> when I ask
> Why do you want to add foo/bar/baz to Release:?
> is usually something along the lines of
> So that I can more easily identify which packages are foo/bar/baz.
> which is an acceptable answer for adding foo/bar/baz identifiers.
> However, it is not really a good answer if foo/bar/baz are displayed
> everywhere. The fault in the reasoning neglects the case that not
> every identification needs foo/bar/baz precisely displayed just because
> foo/bar/baz exists.
I think it actually is useful, it identifies distribution and distribution
just by looking at the filename. Of course one could say that the user
could get this info by querying the rpm, but most people don't do that,
and it's also convenient when searching for files locally or online.

> 3) Why not a URI rather than continuing to append suffixes with
> hints on parsing boundaries like, say, the "." is a parsing hint
> in     %{RELEASE}.%{DISTTAG}
> A URI has a distinct advantage that '/' or "::" boundary hints are regular
> and predictable. The hierarchy of top-to-bottom as in /bing/bang/boom
> or left-to-right as in bing::bang::boom also assists in building labels
> in context simply and predictably (like baseurl). The mdv2009.1 (and
> the %{?dist} conventions) are much more complicated syntactically.
Well, I was first thinking about using '-' in stead of ':', but I chose ':'
of convenience for the versioning since it's easier to separate the field
starting from right when there's only one '-' and one ':', and it was also
a more consistent with epoch tag something I thought would help
make it clear that the tag is optional. I chose to use
'%{RELEASE}:%{DISTTAG}' in package filename to be consistent with
this again, I could just as well use '%{RELEASE}-%{DISTTAG}' and
I'm not against that, but I'm against using '%{RELEASE}.%{DISTTAG}'
since then it's not clear by looking at the filename what's part of the
release tag or not.

> 4) Longer strings with more complicated structure are increasingly
> useless to package manager implementations. A short list of
> currently known implementations that are trying to remove, not
> add, string redundancy includes:
> EDOS/Mancoosi - replacing strings with an index to hide versioning
> zypp - uses a string store to reduce size .solv files
> rpm.org - added a string store to reduce memory footprint
> and there are several other implementations I'm aware of where the
> increasing length of strings in metadata is visibly becoming a performance
> penalty.
> hth
> 73 de Jeff
> [1] http://en.wikipedia.org/wiki/Tar_baby
> On Dec 19, 2008, at 9:57 PM, Per Øyvind Karlsen wrote:
> I've modified DISTTAG tag to be specified in macros file just like
> and commited it to CVS already.
> Here's my next step, a DISTEPOCH tag where distribution version can be
> added.
> This will change EVR to EVRD which will be represented as
> %{EPOCH}:%{VERSION}-%{RELEASE}:%{DISTEPOCH}, ie. 1:2.3.4-5:2009.1.
> The distepoch tag will behave kinda like the epoch tag in the way that it's
> optional, but
> it's significance in version comparision will be the least.
> ie. this way 1:2.3.4-5:2009.1 will be treated as newer than
> 1:2.3.4-5:2009.0, so this is
> consistent with the behaviour of ie. %{_dist} in Fedora, or %mkrel in
> Mandriva.
> As you see from this, the distribution tag will be kept out of the actual
> versioning,
> while the distribution release will be moved to a new tag separately from
> As the distrib tag is quite nice to have and all, it will still be part of
> the package file name.
> Consider the following ~/.rpmmacros:
> %disttag           mdv
> %distepoch      2009.0
> This will create package with the following filename:
> foo-2.3.4-5:mdv2009.0.x86_64.rpm
> From /usr/lib/rpm/macros:
> %___NVRDA
> %%{NAME}-%%{VERSION}-%%{RELEASE}%%|DISTTAG?{:%%{DISTTAG}%%|DISTEPOCH?{%%{DISTEPOCH}}|}|%%|ARCH?{.%%|SOURCERPM?{%%{ARCH}}:{src}|}:{}|
> %_build_name_fmt    %%{ARCH}/%{___NVRDA}.rpm
> Notice that package filename will only be changed to this new style if
> %disttag & %distepoch is used,
> otherwise old package file name is kept.
> You can also use 'DistTag:' & 'DistEpoch:'  per package basis as with ie.
> 'Distribution:' etc.
> This patch is quite non-intrusive and only of concern to anyone choosing to
> use these tags,
> otherwise you won't be affected by it. There's of course a lot of further
> improvements that
> can be made, but they're not that important initially.
> So WDYT? I personally think this is a very nice solution curing the abuse
> of %release for this
> purpose while providing a standard way for these things as well.
> I'll wait for some comments first in case of any objections before
> commiting, meanwhile
> you can find the patch here:
> http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-5.2-distepoch.patch?root=rpm5distro&view=log
> --
> Regards,
> Per Øyvind
Received on Mon Dec 22 16:21:18 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.