RPM Community Forums

Mailing List Message of <rpm-devel>

Re: rpm-5.0.Z releases and rpm-5.1 ROADMAP

From: Jeff Johnson <n3npq@mac.com>
Date: Tue 05 Feb 2008 - 19:47:22 CET
Message-Id: <CB43A8B1-3490-4C87-B084-90C185E384C0@mac.com>

On Feb 5, 2008, at 11:10 AM, R P Herrold wrote:

> On Tue, 5 Feb 2008, Jason Corley wrote:
>
>>    - integrated depsolver
>
> The issue there, as I see it, is what (existing, additional, new <? 
> >) mechanisms will be devised to specify 'target repositories' to  
> consider in doing the dep-solveing.  A whole set of structures in  
> the yum space have emerged, to specify candidate repositories to  
> use (along with some lily gilding about excludes, and priorities.)   
> Also the format has been tweaked with some changes occasionally.
>

Yes. The representation issues, including using repo-metadata or  
repository container abstractions, need
to be separated from fundamental store-and-forward transport  
mechanism implementation.

There are further implementation issues, such as python urlgrabber,  
presto delats, mirroring, etc,
that add a 3rd level of design/policy complexity to an already  
muddled issue that
is generally called "depsolving".

> No reason not to accept the hint (pointer) to the top of archives,  
> as per 'createrepo' as that has become familiar, but should one  
> suck in the metadata, or pull it off the observed binary RPM's  
> found?  Debian solved it another way -- should RPM 'grok' /etc/apt/ 
> sources.list as well?
>

Personally I believe that "All of the above." is the only path  
forward for representation
issues. Its often easier to write a converter from an existing  
representation, or to accomodate
an already deployed URI hierarchy, than it is to deploy a Newer!  
Better! Bestest! scheme.

> What other archive identification mechanisms are out there which  
> need to be considered which I have missed? BSD ports pointers? HP  
> Depot pointers ;) ?
>

Please start making a list.

repo-md XML, yum sqlite, apt Packages, and MacPorts port tree structure
w rsync transport are the representations I'm currently aware of that  
I believe
are important to accomodate near term.

There's also the 0install/klik2/zypper representations that are  
increasingly important, but
I've spent less time studying. So far I like 0install best ...

73 de Jeff
Received on Tue Feb 5 19:48:15 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.