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