[gentoo-osx] Re: [RFC] Separate alt-prefix repo for base-system packages.

[Kito]

On Aug 29, 2005, at 2:07 AM, Brian Harring wrote:

> Kindly cc me on responses- I'm not on the osx mailing list anymore due
> to too much fricking mail per day :)
>
>>> From: kito
>>
>
>
>>> In the interim it can simply be an overlay, using a portage
>>> snapshot, giving us free reign to do what is needed to get the
>>> important things working without having to worry about Apple
>>> provided files. Then with some simple PATH mangling(think finks /sw/
>>> init) we can start making use of it now and actually be a step
>>> ahead of the game.
>
> You're not stating how the path mangling will occur, without
> addressing this the future merging of this proposed tree and the
> mainline tree is questionable.

Fink handles this using a patched bash with a special set of init  
scripts [1]. We would probably have to do something similar, but a  
lot more flexible and dynamic of course, we have to support a lot  
more archs. Even the current profile setup should offer some of the  
functionality required to achieve this.

>
>
>>> Doing this outside the main tree has IMHO worked quite well for g/
>>> fbsd project, and allowed them to get their base-system in order
>>> before they had to go mucking up the tree with hacks that may or
>>> may not be permanent, and is also the reason they aren't hated
>>> quite as much as us by the other projects...
>
> Different angles though; their goal was to nail down a base, and
> integrate the changes *back* into the tree.

Same goal. As I said in my other email, getting too far away from  
main tree must be avoided.

>
> Why am I implying this would basically result in a fork of the tree?
> Their modifications were patches, tweaks to the existing ebuilds such
> that they played nice with *bsd; yes, bit more complex then that, but
> roughly the jist.
>
> Swiveling the offset isn't just swiveling root; any alt offset is
> going to require making the ebuild aware of the offset.  How?

My current thoughts on this is to store all the package metadata in  
Xarchives, probably do it as a portage feature. So we use something  
like the ICANINSTALLTO var (gotta find a better name for that, ugh)  
and each offset filesystem structure is stored in the archive TOC,  
with the optional actual binary package as well if enabled in  
FEATURES, along with all the other typical data stored in /var/db/ 
pkg, almost like a tiered bom(5) file + a lot more.

Initially in practice we would probably ONLY swivel /, with a flat  
set of dependencies, and then work up from there.

If we have accurate *DEPENDS, we just have to make sure portage has  
sufficient knowledge of how to supply them for every offset.

>
> Likely introduction of a new feature/var- how is this going to be
> built up in a seperate repo, then brought back and merged into the
> tree?

EAPI comes to mind, if this is done right, we start establishing an  
ebuild API version that supports offsets.

>
> Mind you I'm not stating that for osx stuff it should be installed
> to / ;
> I'm just trying to point out that the issue of having the offset
> dynamic isn't really addressed, all y'all can do if you don't address
> that issue is build up a repo of ebuilds that have a different set of
> hardcodings, effectively a fork that cannot be merged with the tree
> till a proper solution for swivelling the offset is created.

I'm definitely not interested in a bunch of hacked ebuilds with a  
hardcoded prefix. The whole goal would be doing it in a manner where  
no matter how/when a stable portage supports it, we would be ready,  
and hopefully helped in ushering it along.

>
> The nasty details of it can be found in the -dev thread from a few
> months back re: ICANINSTALLTO ; personally, it's something I'd like
> but not something willing to push atm, due to the fact already have
> enough people screaming that I'm trying to shove more work onto devs.

We would be the devs to not mind some more work =) Instead of an 8  
month long ML thread, we can use this as a sandbox and a constant  
running proof-of-concept. Should also be a good place to get the UI  
side of the portage rewrite hashed out, as emerge and repoman would  
definitely need some serious tweaking for this.

>
> Either way, you could split out the bases, but the point re: how to
> have those bases used by other packages (whether via modification of
> ebuilds, or portage) needs to be addressed, and imo someone should
> have a pretty good idea of the dynamic offset bit, so that the repo
> can be merged back in down the line. Yes, overblowing it a bit re: the
> packages that would depend on the base, but it's possible and likely
> will be raised by others if you do this.

Agreed, and I don't think you are overblowing the need to do it  
right, which is why i CC'd you, I'd like to have the portage people  
involved as much as possible.

--Kito

[1] http://cvs.sourceforge.net/viewcvs.py/fink/base-files/init.sh.in? 
rev=1.19&view=markup
-- 
gentoo-osx@g.o mailing list