Upcoming changes (in 1.4.1)

[Jeff Johnson]

On Aug 15, 2011, at 11:14 AM, Anders F Björklund wrote:

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

So do what Unity does for base url … Mandriva needs to take
off the blinders and get away from its own speshully painful
markup spewage . Or -- equivaently -- someone needs to port
URPMI to non-Mandriva systems.

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

Given *any* sort of identifier that is conventionally/reliably
attached, I can arrange for transforms to make the data
useful. ATM there is nada/zippo/empty/missing info ...

Otherwise we can discuss
	My spewage is better than your spewage because …
for another decade.

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

rpm lib does a callback asking for a header and an opened FD_t
in order to perform an install. The FD_t actually returns the
local path and I can use that instead if smart ceases to use
fdDup, or sets the path that was actually opened in the FD_t
(there's stat(2) info attached to the FD_t that might be set: fdDup
doesn't supply the necessary info).

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

Yep: August 12th was the deadline I set (and I know my own decision path).

> At any rate, not using any newer rpm-python features…
> 

Understood.

73 de Jeff