From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.50) id 1EWem8-0004Fc-DO for garchives@archives.gentoo.org; Mon, 31 Oct 2005 18:52:57 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id j9VIqZN2006793; Mon, 31 Oct 2005 18:52:35 GMT Received: from poober.local (adsl-65-67-32-69.dsl.austtx.swbell.net [65.67.32.69]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id j9VIqXI8026933 for ; Mon, 31 Oct 2005 18:52:34 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by poober.local (Postfix) with ESMTP id 68E96D32AA for ; Mon, 31 Oct 2005 12:52:20 -0600 (CST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-osx@gentoo.org Reply-to: gentoo-osx@lists.gentoo.org Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20051030104901.GA15227@gentoo.org> References: <20051030104901.GA15227@gentoo.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <376467D8-BCFC-4A3C-9512-1AD1C32CB00B@gentoo.org> Content-Transfer-Encoding: 7bit From: Kito Subject: Re: [gentoo-osx] The road ahead? Date: Mon, 31 Oct 2005 12:52:19 -0600 To: gentoo-osx@lists.gentoo.org X-Mailer: Apple Mail (2.746.2) X-Archives-Salt: eb919970-c80b-405c-b3a8-b552f30cf355 X-Archives-Hash: a2204875f848ffd00cb580578181615d 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 -- gentoo-osx@gentoo.org mailing list