Upcoming changes (in 1.4.1)

[Jeff Johnson]

On Aug 15, 2011, at 9:09 AM, Anders F Björklund wrote:

> Jeff Johnson wrote:
> 
>>> Here's a list of the upcoming changes in Smart 1.4.1:
>>> 
>>> - Changes to RPM version comparison, @arch and :distepoch
>>> 
>>> Some distributions, like Unity 2011 and Mandriva 2011,
>>> now append a "Distepoch" component to the traditional
>>> Epoch, Version, Release (EVR) tuple. This needs to be
>>> handled in the parsing code, even if not used by smart.
>>> 
>>> All version comparisons now need to use "vercmp" rather
>>> than "strcmp", so that they account for these tuples.
>>> There is a new helper function added called "checkver",
>>> which compares two version strings for equality (bool).
>>> 
>> 
>> Should some of this be pushed into rpm-python?
> 
> I believe proyvind pushed some of it into python/,
> as a replacement for the old (tuple) labelCompare ?
> 

Good. There's hope that version comparison methods can be done
on opaque uninterpreted strings, with or without adornments
like %{?dist} and Distepoch:/Disttag: etc, if there's a common
code path used.

> It is called evrSplit and evrCompare, apparently...
> For accessing rpmEVRparse and rpmEVRcompare, that is.
> 
> Here is "checkver", it doesn't really add much:
> 
> def checkver(v1, v2):
>    if v1 == v2:
>        return True
>    cmp = vercmp(v1, v2)
>    return cmp == 0
> 
> Where the "vercmp" would be parse-and-compare.
> 
>> Could you also try to populate the repository origin
>> of the package? This should be pretty simple:
>> 	A call to headerSetOrigin() somewhere.
> 
> Sure, that could be done (with the package URL)...
> 
> The "problem" is that the original URL is "lost"
> between the calls in smart, so it would have the
> local URL to the cache directory which is probably
> not what you want (as it is deleted after install)
> 

You could spit into a per-repository baseURL, and
then recover a URI from the baseURL+NEVRA.rpm, if
each package "knows" what repository it came from.

The URI should be thought of like an XQuery URI: i.e.
it need not be found by a browser, could/should include
a hierarchical path description, including "main" <-> "contrib"
like in Mandriva, or "i586" <-> "x86_64" as is always present.

Adding a transform from an XQuery like URI to something
that can be downloaded would always be necessary: mirrors come and go.

But for tracking purposes, the actual mirror used for the download
would be besets.

> So it would need to "save" the URL somewhere first.
> 
>> There's also (used by rpmrepo but otherwise mostly *shrug*)
>> in diminishing priority:
>> 	headerSetDigest()
>> 	headerSetStatbuf()
>> 	headerSetStartOff()
>> 	headerSetEndOff()
>> 	headerSetBaseURL()
>> that would make it easier to re-generate repo-md spewage directly
>> from whatever is installed by smart in an rpmdb.
> 
> Hmm, wonder what digest to use or what base URL ?
> But I suppose those could be set, before addInstall.
> 

The immediate usage case is to be able to generate repo-md
spewage from /var/lib/rpm/Packages that might then be
used exactly as is for a repository. So fill-in-the-blanks
with the usual conventional values, use "UNKOWN" or "" if
you are lazy.

> None of them seem to exported to python, it seems.
> Could be done from C, using a extension callback…
> 

Just as easy would be to move these to the API (i.e.
static inline's in rpmtag.h) and compile into a rpm version
specific module in smart with stub-outs for other versions of rpm.

That keeps the issue as a private deal between thee and me,
no cafeteria food fight is necessary.

But there are simple getter/setter stubs, could (and likely should) be
wired up as fields in a header object, which python _SHOULD_ handle
transparently in __init___ if not @rpm5.org rpm-python in use.

(aside)
I'm still seriously considering just dumping rpm-python (and rpm-perl and rpmbuild)
and walking quietly away from a massive amount of "support" pain that I'm tired
of discussing: life is short ...

73 de Jeff