On Aug 29, 2005, at 10:26 PM, Brian Harring wrote:
> On Tue, Aug 30, 2005 at 01:09:49PM +1000, Finn Thain wrote:
>>> I was looking at it more as a place to develop some new portage
>>> features...Gentoo/Darwin has always been lurking, this is more in
>>> area of just getting offsets working.
>> Excepting that, if you can leverage
>> existing packages, prefixed installs are much more useful -- having a
>> complete set of deps installed on a prefix is not much better than a
>> stage3 chroot with your home directory bind mounted below it.
Maybe so, but we can't have one without the other. First get packages
to install in a prefix, then work up from there. The issue of
leveraging existing packages is currently handled by
package.provided, which we all know doesn't really serve our
purposes, but I see no reason work couldn't be done in parallel on
these issues...if you have an ebuild repo talking to and
understanding a vendor repo such as apples Receipts or whatever, that
will work wether the packages get installed in a prefix or not,
likewise if we have packages that can be installed to an alt-prefix,
they should work regardless of how portage is resolving the deps.
> The rewrite's general core is intended to allow for alt
> formats/repos/whatever jammed into it; that said, making seperate
> formats play nice with each other (unless they can natively) isn't
> something I think is incredibly easy to pull off, as mentioned above.
Right, this would be a great feature, but I look at this as multi-
level deps, which should come later IMHO. My goal for having a branch
of some base packages is to hash out the namespace and all the other
issues of portage managing a flat set of deps under an offset root.
Once that is functional, making the offset repo talk to another repo,
regardless of vendor, host, location, etc could be looked at.
I know that its good to get a solid design before running off and
writing a bunch of code, but it seems to me the portage rewrite has
been thought out sufficiently to allow for this type of feature
expansion in the future, without limiting what we can do right now.
email@example.com mailing list