kito at gentoo
Oct 31, 2005, 5:51 PM
Post #14 of 58
(2374 views)
Permalink
|
On Oct 31, 2005, at 6:16 PM, m h wrote:
> Kito-
>
> Are you leveraging the work done by Haubi documented here:
> http://gentoo-wiki.com/HOWTO_Use_prefixed_portage_%28in_development%29
> ???
Yeah, Brian backported his 2.1 patch to 2.0, and we've had some
additional changes like strict PATH handling(portage requires the
toolchain to live in ${PREFIX}), no use of ${AFFIX} (save that for
later, when portage can manage interdomain deps), ${D} and ${ROOT}
autoexpanded to ${BUILDDIR}/image/${PREFIX} in the ebuild env to
limit the required changes to ebuilds, addition of the ${DEST}
variable for make install DESTDIR targets, also some extra ebuild.sh
functions for setting custom bindir,infodir,sysconf,libdir
configuration options in non-econf configured ebuilds, and various
do* utils fixes.
As it sits right now, the ebuild changes required are very very
minor, which is of utmost importance if this is ever going to fly.
>
> 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.
Excellent. As I mentioned earlier, later this week I hope to get some
barebones docs and the overlay checked into the alt svn repo. The
current method will require arch specific tarballs, so hopefully we
can coordinate effort on this as I've only been targeting Darwin/
OSX... the more portable it is, the better.
--Kito
>
> matt
>
> On 10/31/05, Kito <kito [at] gentoo> 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
>> --
>> gentoo-osx [at] gentoo mailing list
>>
>>
>
> --
> gentoo-osx [at] gentoo mailing list
>
--
gentoo-osx [at] gentoo mailing list
|
1
