Upcoming changes (in 1.4.1)

[Anders F Björklund]

Jeff Johnson wrote:

>> 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.

Especially for Mandriva, where there is no BaseURL...

I have split the channel setup information into
"server" and "directory", but the URL seen will
always been one of the currently selected mirrors.

Fedora's yum repositories have the same problem,
but there it "cheats" and reads the commented out
baseurl for a sane value to use beyond the mirrors.

Currently, only the name of the channel is recorded.

> 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.

This is doable, but currently there is only "pkgpaths"
and the URL used is thrown away (not carried further)

>> 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.

Likely it's just going to be a callback using the path.
Then the other values can be set, using the rpm file ?

>> 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.

That is what was done for the (conditional) rpmvercmp.
Could be done for the above, even if not for 1.4.1...

> 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 ...

Didn't that already happen ? But maybe it was more
about "deleting" than the "leaving it alone to die".

At any rate, not using any newer rpm-python features...

--anders