Kito- Are you leveraging the work done by Haubi documented here: http://gentoo-wiki.com/HOWTO_Use_prefixed_portage_%28in_development%29 ???
Just wondering because I've been able to use this to get portage installed on a FC4 system (I know it's not OSX). But another user has been able to use this to install over 200 packages on an AIX system. matt On 10/31/05, Kito <[EMAIL PROTECTED]> wrote: > > On Oct 30, 2005, at 4:49 AM, Grobian wrote: > > > Since it "is silly if you want things to work before several years > > off" > > [1], perhaps it's not that useful to discuss this issue. However, we > > can all dream, can't we, so let's just do it(tm). > > > > I will try to carve a few roads in the sand in this mail that should > > somehow reflect what I think the things to discuss are, if we really > > want to get moving towards our holy grail. Considering [1], this > > might > > be all useless afterward, but ok. > > > > My personal targets for this project are as follows: > > 1. Make Gentoo for OSX an acceptable sub-project of the Gentoo family. > > 2. Get a prefixed install to make Gentoo for OSX comparative to > > Fink and > > Darwin Ports, and quality wise go beyond. > > Why (2) is not first on everyones priority list, I really don't > understand. If we can do (2) in a reasonably sane fashion, (1) will > 'just happen'. > > > > > Both two targets require some extra explanation. > > 1. Gentoo for OSX functions as "black sheep" of the Gentoo family. In > > that way we put a spell on not only ourselves, but also on the > > Gentoo/Alt project -- which is a good candidate for the second > > black > > sheep. It may be just that some people don't like the smell of non > > GNU/Linux stuff, but there are also constructive comments which > > cannot be denied. > > - My current stategy is to just show some goodwill, by for instance > > reacting swift and accurate to security bugs, as my impression is > > that those have been ignored in the past. But not only securty > > bugs, all bugs where we get involved I try to react within > > reasonable time, just to show we care. Well I do. Of course any > > support in this gets a warm welcome from me. > > - In cooperation with others (mostly vapier) I try to reduce the > > ebuild "spam" caused by ppc-macos. An example is the big > > anti conditional bug [2] which unfortunately hasn't got much of > > my attention yet. The idea is simple: make unconditional stuff > > just to ease maintenance and keep ebuilds slim and pure. > > 2. A prefixed install for me means having a way to install into > > /Library/Gentoo, /Gentoo, /Users/Library/Gentoo or wherever. I > > don't > > really care about the location, and a system wide install would be > > fine with me too. I envision that a touch discussion on variable > > prefixes, or homedir prefixes and whatever will follow if not yet > > have been on the portage channels. What I would like to see is > > that > > we can play with it, maybe not in its ideal state, but those > > improvements can be made while we're playing. > > My impression is everyone in the OS X team feels this is something > thats going to get immaculately implemented by the portage gods, > leaving us to reap the benefits.... not likely... If we don't do the > work, no one will. I've been trying for months to no avail to get > others involved so we can start 'playing with it'. Can lead a horse > to water but can't make him drink I suppose... > > > - Although I have seen signals that we're close to something like > > this (kudos to Kito and Brian) > > I have a self-hosting toolchain working in a prefix right now. Tons > of bugs, tons of things not implemented yet, etc. etc. but its a > solid start. Keep in mind, this should only be considered a proof-of- > concept, mainly to help determine the requirements of the ebuilds > when working in a prefixed environment. > > My rough plan is to squash a few of the major bugs left (collision- > protect and binpkgs primarily), with brians help roll a new patch > against current stable portage(using rc4 currently), check my overlay > into the alt svn module, create a "developers preview" install pkg, > and then continue adding ebuilds to the EAPI=1 overlay, adding > features/bug squashing as we go. Once the overlay is in a fairly > workable state, we can start/continue the beloved GLEP/Flaming > process we all know and love. > > Brian has better insight than I on the long-term roadmap, so > hopefully he'll chime in here, but my guess is the very very earliest > we could see prefixed support in mainline would be around the time of > saviours(3.0) official release... but in the meantime there is by no > means any shortage of work to be done... > > All that being said, the more people working towards this same goal, > the higher the probability of its success and eventual adoption by > Gentoo proper. > > > in the mean-while I try to cope with > > the bugfloods ;). Keywording the low-hanging fruit (those > > ebuilds > > with little or none USE-flags that just compile out of the box) > > reduces the number of open bugs and should be ok when in a prefix > > too. Having more keyworded in portage prepares us a bit for the > > grand "Fink challenge" too. > > - To reach a good quality we will have to reenable the normal > > keywording scheme again. This will only be done once we have a > > prefixed installer. From that point, the imlate scripts and such > > count for us too. Problem there is that we will have to maintain > > the whole tree, like for instance the AMD64 guys do. We're > > outnumbered and hence I think we could use some extra devs that > > have more free time on their hands than most of us now. > > Again, I think that once a product exists that is actually useful, > both devs and users a like will start showing up...bit of a chicken/ > egg situation I know, but this is opensource, without a strong > userbase, we won't ever have a strong dev team. > > > > > To conclude a short note on various flavours of the project, such as > > progressive and darwin. I am not interested in those myself. My main > > focus is on the 'consumer product', which should be the mainline > > product, or the collision-protect profiles as they are called now. > > The > > fact that I am not interested (yet) into these profiles, does not > > mean I > > will never support them. I would just like to focus on getting the > > mainline (normal users) product going, then if people have a personal > > target to create a progressive profile for instance, I will not stop > > such development -- not even wondering on how I would be able to > > stop it > > anyway. I consider one of my personal wishes for a 64-bit install to > > be a profile that should walk the same path like a progressive > > profile: > > it should wait till there is a working mainline product. > > To follow that logic, why are we continuing to mark things ~ppc-macos > when we don't even have a working a mainline product? I look at the > progressive profile about the same as you look at mass keywording for > all of dirks bug reports..."Its not extremely useful right now, but > the work will have to be done at some point, so why not now?" > > Building a prefixed stage1 went extremely quickly because most of the > base-system packages had already been ported to OS X via my work with > the base-system people(ok, mainly just spanky ;) on the progressive > profile(perl,bash,coreutils,gcc- > apple,flex,bison,python,auto*,texinfo,zlib,bzip2,rsync, etc. etc.). > This attitude of 'we only support the consumer product' is a good > outward goal, but is also what IMHO contributed to the half-assed > nature of the current collision-protect profiles...i.e. "We have a > very short sighted implementation, that is a maintenance nightmare, > requires very heavy modifications to the tree, and has virtually 0 > appeal to both devs and users, but lets keep working hard and try to > get gaim and x-chat keyworded ppc-macos because its what users want." > > What I'm saying is, darwin and progressive provide a testbed for the > bottom-up approach that we should have been taking from the beginning. > > --Kito > -- > [email protected] mailing list > > -- [email protected] mailing list
