Re: [gentoo-portage-dev] allow extra info to be echod on die
On Wed, Oct 05, 2005 at 04:33:17PM +, Thomas Matthijs wrote: Hi, I would really like a way to echo more information when a die happens so the users can paste it in their bug report Only needs a very simple change to ebuild.sh: EBUILD_DEATH_HOOKS='' diefunc() { local funcname=$1 lineno=$2 exitcode=$3 shift 3 @@ -289,6 +291,7 @@ echo !!! ${*:-(no error message)} 2 echo !!! If you need support, post the topmost build error, NOT this status message. 2 echo 2 + for x in $EBUILD_DEATH_HOOKS; do + ${x} $1 $2 $3 + done exit 1 } ^^^ something like that I think is a bit better; passing the diefunc args to the hooks also. ~harring pgpiX7sVt5WS1.pgp Description: PGP signature
Re: [gentoo-portage-dev] allow extra info to be echod on die
Just an addendum to this... it went in, will be available in 2.0.51_rc4 and up. If you want all registered death funcs to kick in, EBUILD_DEATH_HOOKS=$EBUILD_DEATH_HOOKS the_name_of_your_func or if you want just your func to run EBUILD_DEATH_HOOKS=the_name_of_your_func CC'ing gentoo-dev, since I'd expect some devs would be interested in it. ~harring On Wed, Oct 05, 2005 at 11:48:01AM -0500, Brian Harring wrote: On Wed, Oct 05, 2005 at 04:33:17PM +, Thomas Matthijs wrote: Hi, I would really like a way to echo more information when a die happens so the users can paste it in their bug report Only needs a very simple change to ebuild.sh: EBUILD_DEATH_HOOKS='' diefunc() { local funcname=$1 lineno=$2 exitcode=$3 shift 3 @@ -289,6 +291,7 @@ echo !!! ${*:-(no error message)} 2 echo !!! If you need support, post the topmost build error, NOT this status message. 2 echo 2 + for x in $EBUILD_DEATH_HOOKS; do + ${x} $1 $2 $3 + done exit 1 } ^^^ something like that I think is a bit better; passing the diefunc args to the hooks also. ~harring pgpe8Zpe3I0pn.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Wed, 5 Oct 2005 11:35:18 -0700 m h [EMAIL PROTECTED] wrote: | I'm working on trying to get prefixed installs working. You might want to start with a proper (not content-free like the last two attempts) requirements spec and design before you jump in with the code. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpkrE2gJ3tDk.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
m h wrote: Hey Folks- I'm working on trying to get prefixed installs working. (As such, I'm using some code kindly modified by Michael Haubenwallner. ) I'm now in python code (portage) and would like to compare what I have with gentoo proper. Is this the location of the latest up to date portage code (in CVS, I realized devs might have more up to date code on their boxes): http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/pym/?root=gentoo-src I looked through the dev documentation but couldn't find anywhere where it stated the actual location of the code in CVS. Any pointers would be great. thanks, matt ps. The issue I found is with pym/cache/fs_template.py. If I'm running as root (GID = 0) then this fails: def __init__(self, label, auxdbkeys, basepath=None, gid=-1, perms=0664, **config): throws InitializationError if needs args aren't specified if not gid: raise cache_errors.InitializationError(self.__class__, must specify gid!) Shouldn't the logic be if gid != -1? I don't have access to a gentoo proper box right now... I thought that part of brian's domain stuff in Savior was to cover this. In either case no one should be writing any real code at this point since no one has agreed on any sane way to pull this off. There needs to be plenty of healthy discussion the pro's and con's of how things should be done in regards to *-prefix. In conclusion, if you think this will be 'easy', think again ;) PS. However starting discussion on how exactly this would work might be a nice thing to do ;) -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
Sorry, on further reading of my post, my questions weren't clear. My first question is where is the current head of portage in CVS? (I'd like to compare with what I have, and I'm not sure if I'm looking in the right place). WRT implementing Prefix. I'm looking at Michael's code, because I want to see what he has done. (Which seems to be inline with what I need, may or may not align with the gentoo community at large, since nothing has been decided on that front). Though, I noticed there was mention of Prefixed installs in yesterdays GWN (http://www.gentoo.org/proj/en/gentoo-alt/). If anyone can elaborate on the efforts going on in that arena, I'm all ears. matt On 10/5/05, Alec Joseph Warner [EMAIL PROTECTED] wrote: m h wrote: Hey Folks- I'm working on trying to get prefixed installs working. (As such, I'm using some code kindly modified by Michael Haubenwallner. ) I'm now in python code (portage) and would like to compare what I have with gentoo proper. Is this the location of the latest up to date portage code (in CVS, I realized devs might have more up to date code on their boxes): http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/pym/?root=gentoo-src I looked through the dev documentation but couldn't find anywhere where it stated the actual location of the code in CVS. Any pointers would be great. thanks, matt ps. The issue I found is with pym/cache/fs_template.py. If I'm running as root (GID = 0) then this fails: def __init__(self, label, auxdbkeys, basepath=None, gid=-1, perms=0664, **config): throws InitializationError if needs args aren't specified if not gid: raise cache_errors.InitializationError(self.__class__, must specify gid!) Shouldn't the logic be if gid != -1? I don't have access to a gentoo proper box right now... I thought that part of brian's domain stuff in Savior was to cover this. In either case no one should be writing any real code at this point since no one has agreed on any sane way to pull this off. There needs to be plenty of healthy discussion the pro's and con's of how things should be done in regards to *-prefix. In conclusion, if you think this will be 'easy', think again ;) PS. However starting discussion on how exactly this would work might be a nice thing to do ;) -- gentoo-portage-dev@gentoo.org mailing list -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
Yay, time for another flame war (just what I'd love to spend my time on). On Wed, Oct 05, 2005 at 04:06:47PM -0400, Alec Joseph Warner wrote: Hey Folks- I'm working on trying to get prefixed installs working. (As such, I'm using some code kindly modified by Michael Haubenwallner. ) I'm now in python code (portage) and would like to compare what I have with gentoo proper. Is this the location of the latest up to date portage code (in CVS, I realized devs might have more up to date code on their boxes): http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/pym/?root=gentoo-src I looked through the dev documentation but couldn't find anywhere where it stated the actual location of the code in CVS. Any pointers would be great. We've moved to svn, which will be available via viewcvs shortly. Anonymous svn is available if you poke your head into irc.freenode.net #gentoo-portage, and pull it from the /topic. The issue I found is with pym/cache/fs_template.py. If I'm running as root (GID = 0) then this fails: def __init__(self, label, auxdbkeys, basepath=None, gid=-1, perms=0664, **config): throws InitializationError if needs args aren't specified if not gid: raise cache_errors.InitializationError(self.__class__, must specify gid!) Judging by location, that's 2.1. The extra opts are directly changable via configuration under the rewrite's code, so setting gid isn't hard. Shouldn't the logic be if gid != -1? I don't have access to a gentoo proper box right now... Yah. That said that code's been corrected under the rewrite. I thought that part of brian's domain stuff in Savior was to cover this. In either case no one should be writing any real code at this point since no one has agreed on any sane way to pull this off. There needs to be plenty of healthy discussion the pro's and con's of how things should be done in regards to *-prefix. There was plenty of discussion about it last time around. It got sunk due to the fact that ciaran was a bit hell bent on having HOME integrated into it. All or none, was effectively the issue. The current line of thought on it is global prefix going in as an addition to an EAPI release, _strictly_ global prefix. The home crap (interdomain deps, querying information/location of package X) being a later release. Why? Doing prefix is hard. Doing prefix + home is harder. A global offset for PREFIX is going to require a fair amount of work. Tacking home into it (something that a global offset does _not_ require) is sadling a requested feature with a lesser feature. Do 'em seperate. Those who want interdomain, they can do the work. Those who want global offset, they can do that chunk. To head off the it's not going to work for vim-*, yah, you'll be boned and have to install duplicate vim-* into the global prefix. Bluntly, either you dive in and start wading through the problems (fixing them as you go), or you sit back listening to how it's never going to work (thus accomplishing nothing). ~harring pgpNB0H1f7KlS.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
m h wrote: Sorry, on further reading of my post, my questions weren't clear. My first question is where is the current head of portage in CVS? (I'd like to compare with what I have, and I'm not sure if I'm looking in the right place). WRT implementing Prefix. I'm looking at Michael's code, because I want to see what he has done. (Which seems to be inline with what I need, may or may not align with the gentoo community at large, since nothing has been decided on that front). Though, I noticed there was mention of Prefixed installs in yesterdays GWN (http://www.gentoo.org/proj/en/gentoo-alt/). If anyone can elaborate on the efforts going on in that arena, I'm all ears. matt On 10/5/05, Alec Joseph Warner [EMAIL PROTECTED] wrote: m h wrote: Hey Folks- I'm working on trying to get prefixed installs working. (As such, I'm using some code kindly modified by Michael Haubenwallner. ) I'm now in python code (portage) and would like to compare what I have with gentoo proper. Is this the location of the latest up to date portage code (in CVS, I realized devs might have more up to date code on their boxes): http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/pym/?root=gentoo-src I looked through the dev documentation but couldn't find anywhere where it stated the actual location of the code in CVS. Any pointers would be great. thanks, matt ps. The issue I found is with pym/cache/fs_template.py. If I'm running as root (GID = 0) then this fails: def __init__(self, label, auxdbkeys, basepath=None, gid=-1, perms=0664, **config): throws InitializationError if needs args aren't specified if not gid: raise cache_errors.InitializationError(self.__class__, must specify gid!) Shouldn't the logic be if gid != -1? I don't have access to a gentoo proper box right now... I thought that part of brian's domain stuff in Savior was to cover this. In either case no one should be writing any real code at this point since no one has agreed on any sane way to pull this off. There needs to be plenty of healthy discussion the pro's and con's of how things should be done in regards to *-prefix. In conclusion, if you think this will be 'easy', think again ;) PS. However starting discussion on how exactly this would work might be a nice thing to do ;) -- gentoo-portage-dev@gentoo.org mailing list * Now talking on #gentoo-portage * Topic for #gentoo-portage is: 2.0.53_rc3 released; please test || emerge development only; ebuild dev questions go to #gentoo-dev-help and usage questions go to #gentoo || anonsvn access: svn co svn://twobit.net/portage/, rewrite is at main/branches/savior, 2.1 is at main/trunk, 2.0 is at main/branches/2.0 and sandbox is at path-sandbox/trunk IRC is your friend here ;) In this case you probably want the rewrite, which is from what I recall, a complete rewrite...so nothing of Haubi's is in it. Brian will definately know more there than myself, I haven't touched it in quite some time, and I doubt RL will let me for a bit :P -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Wed, 5 Oct 2005 15:24:29 -0500 Brian Harring [EMAIL PROTECTED] wrote: | To head off the it's not going to work for vim-*, yah, you'll be | boned and have to install duplicate vim-* into the global prefix. | Bluntly, either you dive in and start wading through the problems | (fixing them as you go), or you sit back listening to how it's never | going to work (thus accomplishing nothing). It can be made to work, so long as you don't a) jump in without proper planning, b) assume that you'll not have to modify ebuilds and c) demand that as soon as it's available, it works for all ebuilds. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpDq8Dkk8Yjv.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Wed, Oct 05, 2005 at 09:57:03PM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 15:24:29 -0500 Brian Harring [EMAIL PROTECTED] wrote: | To head off the it's not going to work for vim-*, yah, you'll be | boned and have to install duplicate vim-* into the global prefix. | Bluntly, either you dive in and start wading through the problems | (fixing them as you go), or you sit back listening to how it's never | going to work (thus accomplishing nothing). It can be made to work, so long as you don't a) jump in without proper planning, b) assume that you'll not have to modify ebuilds and c) demand that as soon as it's available, it works for all ebuilds. I'd point out that the last time prefix was brought up, all of those points were addressed. A) would like to hear what you think is required planning wise compared to the previous haubi prototype patch. B) Modifying the ebuilds is required, although modifying the underlying base defaults does cover a good swath of ebuilds C) See previous comments from last round of this stating those who want it, have to do the work. ~harring pgpjCoEJ44DaB.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Oct 5, 2005, at 3:57 PM, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 15:24:29 -0500 Brian Harring [EMAIL PROTECTED] wrote: | To head off the it's not going to work for vim-*, yah, you'll be | boned and have to install duplicate vim-* into the global prefix. | Bluntly, either you dive in and start wading through the problems | (fixing them as you go), or you sit back listening to how it's never | going to work (thus accomplishing nothing). It can be made to work, so long as you don't a) jump in without proper planning Well, then lets plan, not flame. b) assume that you'll not have to modify ebuilds I don't think anyone(devs) has made this naive assumption have they? and c) demand that as soon as it's available, it works for all ebuilds. I don't think anyone(devs) has made this naive demand have they? So, lets address a) and c) since b) is a given. My first question would be how to identify ebuilds that respect $ {prefix}? A separate profile/keyword seems wrong. ICANINSTALLTO was the best idea presented, but that implies it would be a list of known working prefixes, which seems unrealistic. Maybe it would be better to have portage error check that globally at the load_config stage against a list of known stupid prefixes, stupidprefixes=[/usr,/,/bin] etc. etc. --Kito -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Wed, Oct 05, 2005 at 04:16:06PM -0500, Kito wrote: My first question would be how to identify ebuilds that respect $ {prefix}? A separate profile/keyword seems wrong. Agreed. ICANINSTALLTO was the best idea presented, but that implies it would be a list of known working prefixes, which seems unrealistic. DOMAIN is a saner name imo. Aside from that, listing every potential target (/usr/bin, $HOME/bin fex) is whacky and getting into the HOME stuff that comes after. I would suggest root, and offset as the initial targets. root would be implicit if DOMAIN isn't defined, and references / as the prefix. offset is just as it sounds, a root offset, everything from that tree installed at an offset. Maybe it would be better to have portage error check that globally at the load_config stage against a list of known stupid prefixes, stupidprefixes=[/usr,/,/bin] etc. etc. Bit beyond the ken of this discussion, but yah, agreed. ~harring pgpon9LigF1m7.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On 10/5/05, Brian Harring [EMAIL PROTECTED] wrote: On Wed, Oct 05, 2005 at 01:48:03PM -0700, m h wrote: On 10/5/05, Brian Harring [EMAIL PROTECTED] wrote: Yay, time for another flame war (just what I'd love to spend my time on). Sorry, I'm really not trying to kindle any flames here. Heh, you're not, I'm just mildly pissy due to recurrent flamewars :) In which case I'm sorry to be the bearer or recurrent touchy subjects ;) So, on the topic of rewrite. Does there happen to be any testcases for portage? Unittests, etc? I'd be nice to verify that rewrite behaves properly (well, actually I want testcases for selfish reasons, so I don't break code if I change anything) Niadda. Would love it if someone stepped up on that, since I don't particularly have the time right now :) Can possibly help out on that, see below... Do 'em seperate. Those who want interdomain, they can do the work. Those who want global offset, they can do that chunk. I understand the interdomain stuff to be that prefixed packages can depend on packages outside of their prefix? If so, I don't want this feature. I want an isolated sandbox. (Again, I realize others have different needs) Pretty much. Best description is dependencies between root's. Global prefix (for osx) would either A) have a vdb for that prefix that represented the package.provided nodes B) have a domain for root=/, and do interdomain. A is likely route due to it being a helluva lot simpler; B is better/cleaner (imo), but it requires more work. Hmmm, I'm not clear yet on the value of interdomain, but I'm sure someone will enlighten me along the way... So, I figure I'm sortof diving in with Haubi's code (against the advice of those wanted a complete spec) since I think my needs seem to be the most minimum subset of what others want in this feature. I think it's a good way to help me understand the innards of portage (though the code is pretty spaghetti right now). I presume you think I should start with rewrite as a base? What is the current status of rewrite? Rewrite's code is a heck of a lot cleaner; oop based for starters :) There is some nastyness, but it's encapsulated, and pretty much required. Current state of it is that I'm atm stuck on plugin code, and a slight change to the config handling code. Building/fetching are done, full immutable ebuild tree and vdb are done, immutable binpkg repository is done sans a package class. The mutable thing is basically querying the db; for vdb and binpkg, they need to be modifiable, able to add a package to the repository (merging). I'm working on that atm. Jason's doing resolver work, state of that I can't comment on (that's his thing). ebuild*sh side of it's already done- if you were looking to test out prefix building (experiment) I'd probably start there. OK, so since I have a deadline (end of next week) I'd like to have a simple prototype working. IE me running apache on FC4 with portage. If I can do that then it's very likely that I'll be able to devote a bit of time towards working on this (where this could be rewrite) (bug fixes, polishing it up, unittests, etc). On that note, I need to know what the timeframe for rewrite is. If it's to a state where I can work with it then maybe I should try and start from there. But I'm assumming it will be easier/quicker to get haubi's stuff working. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Wed, Oct 05, 2005 at 02:52:59PM -0700, m h wrote: Hmmm, I'm not clear yet on the value of interdomain, but I'm sure someone will enlighten me along the way... interdomain would be how ciaran's HOME request would be pulled off; user's 'domain', configuration settings + prefix offset would try to satisfy deps from the global domain '/'. When it can't, would resort to installing to the user's domain, assuming the ebuild is capable of it. OK, so since I have a deadline (end of next week) I'd like to have a simple prototype working. IE me running apache on FC4 with portage. If I can do that then it's very likely that I'll be able to devote a bit of time towards working on this (where this could be rewrite) (bug fixes, polishing it up, unittests, etc). On that note, I need to know what the timeframe for rewrite is. If it's to a state where I can work with it then maybe I should try and start from there. But I'm assumming it will be easier/quicker to get haubi's stuff working. Haubi's is what I'd recommend. Rewrite isn't anywhere near that sort of timeline. I'd also note realistically pulling it off within 10 days might be tricky, due to the fact it requires ebuild modifications plus dusting off and updating haubi's patch, along with buttload of testing. Or I'm just slow at implementing stuff. :) ~harring pgp7j0hS9Ee6H.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Wed, 5 Oct 2005 16:16:06 -0500 Kito [EMAIL PROTECTED] wrote: | b) assume that you'll not have to modify ebuilds | | I don't think anyone(devs) has made this naive assumption have they? pvdabeel has for pathspec. | and c) | demand that as soon as it's available, it works for all ebuilds. | | I don't think anyone(devs) has made this naive demand have they? pvdabeel has for pathspec. | ICANINSTALLTO was the best idea presented, but that implies it would | be a list of known working prefixes, which seems unrealistic. Maybe | it would be better to have portage error check that globally at the | load_config stage against a list of known stupid prefixes, | stupidprefixes=[/usr,/,/bin] etc. etc. The plan was to have ICANINSTALLTO=root home prefixed or somesuch. The name isn't particularly clear on that... -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp6Nbtw6j315.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Wed, 5 Oct 2005 16:13:06 -0500 Brian Harring [EMAIL PROTECTED] wrote: | A) would like to hear what you think is required planning wise | compared to the previous haubi prototype patch. There has been no serious discussion on how *ebuilds* will use the prefix system. Hacking econf and expecting PREFIX to be sufficient is naive from a tree-perspective. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgprvYY2wTOts.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Wed, Oct 05, 2005 at 11:29:56PM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 16:16:06 -0500 Kito [EMAIL PROTECTED] wrote: | b) assume that you'll not have to modify ebuilds | | I don't think anyone(devs) has made this naive assumption have they? pvdabeel has for pathspec. | and c) | demand that as soon as it's available, it works for all ebuilds. | | I don't think anyone(devs) has made this naive demand have they? pvdabeel has for pathspec. You're not talking to pvdabeel right now, so kindly be quiet about him. Further, don't argue the dev point, no one cares- we're discussing prefix, not getting pulled into tangents of pathspec nor slams at other devs. | ICANINSTALLTO was the best idea presented, but that implies it would | be a list of known working prefixes, which seems unrealistic. Maybe | it would be better to have portage error check that globally at the | load_config stage against a list of known stupid prefixes, | stupidprefixes=[/usr,/,/bin] etc. etc. The plan was to have ICANINSTALLTO=root home prefixed or somesuch. The name isn't particularly clear on that... See email naming it as domain. Home being a later target; not sure about prefixed, but it's as good of a name as any other (arbitrary, in other words). ~harring pgpdiKyxShUiG.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Wed, 5 Oct 2005 18:00:12 -0500 Brian Harring [EMAIL PROTECTED] wrote: | Beyond that, there is the shebang issue which can be addresses via a | combination of automated scans/fixes, and fixing bugs as it's hit. | Hardcoded vars in scripts for the path to a binary are an issue also, | although again, scans can be done to at least check for it. This one's a far bigger issue than might be initially obvious. It would involve rewriting a whole load of autotools innards... | Leaves mangling the build process so that the build framework of the | package uses the prefix offset files, rather then / . For c/c++ | source, usual trick from fink afaik involves a mangling of cflags | with -I tacked in. Kinda ugly, although I'd expect there is a better | route. Again, autoconf tinkering. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpnQhicXqEDx.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Thu, Oct 06, 2005 at 12:14:30AM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 18:00:12 -0500 Brian Harring [EMAIL PROTECTED] wrote: | Beyond that, there is the shebang issue which can be addresses via a | combination of automated scans/fixes, and fixing bugs as it's hit. | Hardcoded vars in scripts for the path to a binary are an issue also, | although again, scans can be done to at least check for it. This one's a far bigger issue than might be initially obvious. It would involve rewriting a whole load of autotools innards... Clarify. My knowledge of autotool innards is that it relies on $PATH for lookup of the tools it uses. | Leaves mangling the build process so that the build framework of the | package uses the prefix offset files, rather then / . For c/c++ | source, usual trick from fink afaik involves a mangling of cflags | with -I tacked in. Kinda ugly, although I'd expect there is a better | route. Again, autoconf tinkering. Statement above is from digging through generated configure script. ~harring pgp3yrxiLkcfh.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
Brian Harring wrote: On Wed, Oct 05, 2005 at 11:31:32PM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 16:13:06 -0500 Brian Harring [EMAIL PROTECTED] wrote: | A) would like to hear what you think is required planning wise | compared to the previous haubi prototype patch. There has been no serious discussion on how *ebuilds* will use the prefix system. Hacking econf and expecting PREFIX to be sufficient is naive from a tree-perspective. econf isn't the only change required; the point is that whatever is decided, would have to be added to econf thus covering a good chunk of ebuilds in the tree that don't require fancy voodoo. The basic proposal of haubi's glep (ignoring the portage innard modifications) came down to addition of a prefix var, that would be required slipped in for any fs installation paths (--prefix=$PREFX fex). Beyond that, there is the shebang issue which can be addresses via a combination of automated scans/fixes, and fixing bugs as it's hit. Hardcoded vars in scripts for the path to a binary are an issue also, although again, scans can be done to at least check for it. Leaves mangling the build process so that the build framework of the package uses the prefix offset files, rather then / . For c/c++ source, usual trick from fink afaik involves a mangling of cflags with -I tacked in. Kinda ugly, although I'd expect there is a better route. Packages that pull include/compile settings/args from a utility (thinking python configuration tools, and pkgconfig) shouldn't be too horrid to change, since it's a matter of modifying it in one place (theoretically :). ~harring I guess in the end trying to do something like this is a difficult process. I am wary of anyone who wants to just jump into an application like portage and just magically write in this kind of support. In the end one could just try and go step by step, but nothing guarantee's you won't miss something, or because it works with packages x,y,z that it will work for all packages. If you have two weeks to do it in, I wish you the best of luck. Maybe you are good enough at learning portage internals to get it done, but even after portage support is done there are still plenty of other factors. In the end I side with Ciaran on this one. You need to know all the bases to cover here in order to make this work well. Going ahead with no plan is stupid IMHO. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
Thanks for the warning Alec. Since I already have very limited knowledge of the internals, I figure this will be a good trial by fire (learn sort of the portage internals and issues with prefixed installs). If it works, perhaps I will be able to devote more time to it and do more than a simple prototype (which might involve writing a spec, talking to Fink people and seeing how they resolved these sorts of issues and all that fun stuff). Right now, I'm not very qualified to write a spec, but I figure when I get my hands into it I'll start seeing a lot more of the issues one is bound to run into. If it's so hard that's it's impossible then maybe I should just give up now What sort of plan do you suggest? On 10/5/05, Alec Warner [EMAIL PROTECTED] wrote: Brian Harring wrote: On Wed, Oct 05, 2005 at 11:31:32PM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 16:13:06 -0500 Brian Harring [EMAIL PROTECTED] wrote: | A) would like to hear what you think is required planning wise | compared to the previous haubi prototype patch. There has been no serious discussion on how *ebuilds* will use the prefix system. Hacking econf and expecting PREFIX to be sufficient is naive from a tree-perspective. econf isn't the only change required; the point is that whatever is decided, would have to be added to econf thus covering a good chunk of ebuilds in the tree that don't require fancy voodoo. The basic proposal of haubi's glep (ignoring the portage innard modifications) came down to addition of a prefix var, that would be required slipped in for any fs installation paths (--prefix=$PREFX fex). Beyond that, there is the shebang issue which can be addresses via a combination of automated scans/fixes, and fixing bugs as it's hit. Hardcoded vars in scripts for the path to a binary are an issue also, although again, scans can be done to at least check for it. Leaves mangling the build process so that the build framework of the package uses the prefix offset files, rather then / . For c/c++ source, usual trick from fink afaik involves a mangling of cflags with -I tacked in. Kinda ugly, although I'd expect there is a better route. Packages that pull include/compile settings/args from a utility (thinking python configuration tools, and pkgconfig) shouldn't be too horrid to change, since it's a matter of modifying it in one place (theoretically :). ~harring I guess in the end trying to do something like this is a difficult process. I am wary of anyone who wants to just jump into an application like portage and just magically write in this kind of support. In the end one could just try and go step by step, but nothing guarantee's you won't miss something, or because it works with packages x,y,z that it will work for all packages. If you have two weeks to do it in, I wish you the best of luck. Maybe you are good enough at learning portage internals to get it done, but even after portage support is done there are still plenty of other factors. In the end I side with Ciaran on this one. You need to know all the bases to cover here in order to make this work well. Going ahead with no plan is stupid IMHO. -- gentoo-portage-dev@gentoo.org mailing list -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Thu, Oct 06, 2005 at 12:38:35AM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 18:22:37 -0500 Brian Harring [EMAIL PROTECTED] wrote: | On Thu, Oct 06, 2005 at 12:14:30AM +0100, Ciaran McCreesh wrote: | On Wed, 5 Oct 2005 18:00:12 -0500 Brian Harring | [EMAIL PROTECTED] | wrote: | | Beyond that, there is the shebang issue which can be addresses | | via a combination of automated scans/fixes, and fixing bugs as | | it's hit. Hardcoded vars in scripts for the path to a binary are | | an issue also, although again, scans can be done to at least | | check for it. | | This one's a far bigger issue than might be initially obvious. It | would involve rewriting a whole load of autotools innards... | | Clarify. My knowledge of autotool innards is that it relies on $PATH | for lookup of the tools it uses. It does in some places, it doesn't in others. It especially doesn't for things that aren't normally found via PATH. It's a hell of a mess. Examples? ~harring pgpqc9GgtRZ5U.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
m h wrote: Thanks for the warning Alec. Since I already have very limited knowledge of the internals, I figure this will be a good trial by fire (learn sort of the portage internals and issues with prefixed installs). If it works, perhaps I will be able to devote more time to it and do more than a simple prototype (which might involve writing a spec, talking to Fink people and seeing how they resolved these sorts of issues and all that fun stuff). Right now, I'm not very qualified to write a spec, but I figure when I get my hands into it I'll start seeing a lot more of the issues one is bound to run into. If it's so hard that's it's impossible then maybe I should just give up now What sort of plan do you suggest? On 10/5/05, Alec Warner [EMAIL PROTECTED] wrote: Brian Harring wrote: On Wed, Oct 05, 2005 at 11:31:32PM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 16:13:06 -0500 Brian Harring [EMAIL PROTECTED] wrote: | A) would like to hear what you think is required planning wise | compared to the previous haubi prototype patch. There has been no serious discussion on how *ebuilds* will use the prefix system. Hacking econf and expecting PREFIX to be sufficient is naive from a tree-perspective. econf isn't the only change required; the point is that whatever is decided, would have to be added to econf thus covering a good chunk of ebuilds in the tree that don't require fancy voodoo. The basic proposal of haubi's glep (ignoring the portage innard modifications) came down to addition of a prefix var, that would be required slipped in for any fs installation paths (--prefix=$PREFX fex). Beyond that, there is the shebang issue which can be addresses via a combination of automated scans/fixes, and fixing bugs as it's hit. Hardcoded vars in scripts for the path to a binary are an issue also, although again, scans can be done to at least check for it. Leaves mangling the build process so that the build framework of the package uses the prefix offset files, rather then / . For c/c++ source, usual trick from fink afaik involves a mangling of cflags with -I tacked in. Kinda ugly, although I'd expect there is a better route. Packages that pull include/compile settings/args from a utility (thinking python configuration tools, and pkgconfig) shouldn't be too horrid to change, since it's a matter of modifying it in one place (theoretically :). ~harring I guess in the end trying to do something like this is a difficult process. I am wary of anyone who wants to just jump into an application like portage and just magically write in this kind of support. In the end one could just try and go step by step, but nothing guarantee's you won't miss something, or because it works with packages x,y,z that it will work for all packages. If you have two weeks to do it in, I wish you the best of luck. Maybe you are good enough at learning portage internals to get it done, but even after portage support is done there are still plenty of other factors. In the end I side with Ciaran on this one. You need to know all the bases to cover here in order to make this work well. Going ahead with no plan is stupid IMHO. -- gentoo-portage-dev@gentoo.org mailing list My point was not to scare you so much as to make you aware of the problems you will face. Most of them are not portage problems. Most of the problems are ebuild problems, found in each piece of software that will be used in this manner. All of the ebuilds are written for one domain, and now they are being used in another. Ciaran has already given a few examples of the trouble. In this case Getting it to work is easy. Getting it to work for all packages = a ton of work. -Alec PS: Nothing I say should stop you, I am by no means an expert. PSS: Good Luck. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Wed, 5 Oct 2005 18:40:46 -0500 Brian Harring [EMAIL PROTECTED] wrote: | It does in some places, it doesn't in others. It especially doesn't | for things that aren't normally found via PATH. It's a hell of a | mess. | | Examples? Of stuff in PATH? /bin/sh is assumed throughout to be a Bourne compatible shell (and SHELL and CONFIG_SHELL aren't universally honoured). uname, hostname and sed are called with hard paths (with various fallbacks) in several early on stages. Of stuff not in path? There's no standard and widely used way of digging up where libexec tools are. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpaizwnjub0S.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Thu, Oct 06, 2005 at 01:13:53AM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 18:40:46 -0500 Brian Harring [EMAIL PROTECTED] wrote: | It does in some places, it doesn't in others. It especially doesn't | for things that aren't normally found via PATH. It's a hell of a | mess. | | Examples? Of stuff in PATH? /bin/sh is assumed throughout to be a Bourne compatible shell (and SHELL and CONFIG_SHELL aren't universally honoured). uname, hostname and sed are called with hard paths (with various fallbacks) in several early on stages. Of stuff not in path? There's no standard and widely used way of digging up where libexec tools are. What's being raised here is issues with making ebuilds handle prefix _perfectly_. Where are the portage issues, so that people can actually jump in and start testing out actual solutions, rather then conjecturing about what may or may not break? ~harring pgpvDKijE0RXh.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Wed, 5 Oct 2005 20:01:34 -0500 Brian Harring [EMAIL PROTECTED] wrote: | What's being raised here is issues with making ebuilds handle prefix | _perfectly_. Where are the portage issues, so that people can | actually jump in and start testing out actual solutions, rather then | conjecturing about what may or may not break? The issue is that you need to fix autoconf before you can claim that any non-trivial test case works correctly. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpuwdeoxEWcC.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Wed, 5 Oct 2005 20:17:40 -0500 Brian Harring [EMAIL PROTECTED] wrote: | The issue is that you need to fix autoconf before you can claim that | any non-trivial test case works correctly. | | And how are you going to verify autoconf works perfectly without | testing it? Can't. Dead easy to verify that it will break without testing it, though. Just look at the source. | The point I'm making is that the only thing required of *portage*, is | the prefix var being used internally, and handed down to the ebuilds. | | Ironing out the ebuild cruft is left to those who want it. Again, | where is the hold up for *portage*? That's rather short-sighted... Portage is irrelevant without the ebuilds. | What's the problem? Why the 101 holes before they even can attempt | it? If you're after shooting the idea down (as I suspect), state so | rather then death by a thousand cuts. Saves us time, really. | | Hell, haubi's patch already lays the ground work for testing it. I'm | not seeing why you're being negative about people even working on it. Because a botched solution is worse than no solution at all. You've seen the mess we end up with when people start working with a half-arsed initial setup. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpEgTt9aTo0S.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Thu, Oct 06, 2005 at 02:23:47AM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 20:17:40 -0500 Brian Harring [EMAIL PROTECTED] wrote: | The issue is that you need to fix autoconf before you can claim that | any non-trivial test case works correctly. | | And how are you going to verify autoconf works perfectly without | testing it? Can't. Dead easy to verify that it will break without testing it, though. Just look at the source. Break is a bit heavy, considering autoconf's usage of /bin/sh is pretty limited in terms of syntax. Looking at the source, it'll revert to / for certain bins. A forced autoreconf with a patched autoconf/autotools is required, but again, doesn't do jack with out testing. | The point I'm making is that the only thing required of *portage*, is | the prefix var being used internally, and handed down to the ebuilds. | | Ironing out the ebuild cruft is left to those who want it. Again, | where is the hold up for *portage*? That's rather short-sighted... Portage is irrelevant without the ebuilds. And ebuilds are irrelevant without portage. Point? My point experimentation can start for addressing the issues you keep pointing at still stands. | What's the problem? Why the 101 holes before they even can attempt | it? If you're after shooting the idea down (as I suspect), state so | rather then death by a thousand cuts. Saves us time, really. | | Hell, haubi's patch already lays the ground work for testing it. I'm | not seeing why you're being negative about people even working on it. Because a botched solution is worse than no solution at all. You've seen the mess we end up with when people start working with a half-arsed initial setup. Well plan the sucker out then, as you advocated, or sit back and let them jump in and start working it out. Perhaps they'll decide it's completely unworkable (I doubt it, considering the fact fink's crappy handling of building has made it this far), or perhaps they'll get it working and you won't have as many holes to point at. Regardless, it's their time to spend working on it. Either chip in, or offer _constructive_ advice, or plain step back and let them try to get it working. Note the constructive. Stating it won't work and pulling a new reason why isn't constructive, pointing out each issue as you see it so they can address it (if it's an issue) is a bit more constructive. ~harring pgpLpvBGoQzGq.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Wed, 5 Oct 2005 20:32:20 -0500 Brian Harring [EMAIL PROTECTED] wrote: | That's rather short-sighted... Portage is irrelevant without the | ebuilds. | | And ebuilds are irrelevant without portage. Point? Portage is considerably less work than the tree. Saving as much effort as possible from an ebuild perspective should be a major consideration, even if it makes the portage side more complicated. Think of how all the ebuild-related problems are going to be solved first. Don't leave it as an afterthought. | My point experimentation can start for addressing the issues you keep | pointing at still stands. The sensible place to start experimenting is by adapting existing ebuilds and tinkering with ebuild.sh, not by adding something which may or may not end up being relevant to portage proper. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpnbNAjoxpwk.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Thu, Oct 06, 2005 at 02:40:58AM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 20:32:20 -0500 Brian Harring [EMAIL PROTECTED] Portage is considerably less work than the tree. Saving as much effort as possible from an ebuild perspective should be a major consideration, even if it makes the portage side more complicated. Think of how all the ebuild-related problems are going to be solved first. Don't leave it as an afterthought. Round and round we go. The ebuild related problems aren't going to be solved in portage till someone has a general solution that can be pushed into portage/ebuild.sh base template. That's something that requires people diving in and screwing with it. | My point experimentation can start for addressing the issues you keep | pointing at still stands. The sensible place to start experimenting is by adapting existing ebuilds and tinkering with ebuild.sh, not by adding something which may or may not end up being relevant to portage proper. Bluntly, what the hell do you think we're talking about here? In case you haven't caught on, there *are* portage modifications that have to go with it, meaning more then ebuild.sh. Regardless, I'll backport haubi's patch to stable if anyone is after screwing with it, unless michael's has a version that applies cleanly to .53_rc4. Enough dancing, would rather hand it off to those who are interested, and see what they come up with rather then fencing via email (and accomplishing nothing). Michael, got anything I can mold to .5*, or just backport the 2.1 mod? ~harring pgpmLvkkFehel.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Oct 5, 2005, at 7:13 PM, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 18:40:46 -0500 Brian Harring [EMAIL PROTECTED] wrote: | It does in some places, it doesn't in others. It especially doesn't | for things that aren't normally found via PATH. It's a hell of a | mess. | | Examples? Of stuff in PATH? /bin/sh is assumed throughout to be a Bourne compatible shell (and SHELL and CONFIG_SHELL aren't universally honoured). uname, hostname and sed are called with hard paths (with various fallbacks) in several early on stages. Of stuff not in path? There's no standard and widely used way of digging up where libexec tools are. Its not like this is unchartered territory... off the top o' me head pkgsrc, DarwinPorts, openpkg, fink, written word, autopackage, MINE, and SamHain have all tackled this in one way or the other. All of these projects have their faults (duh? but then again so does portage and the ebuild tree) but a few of them have been quite successful despite their varying points of inherent silliness. --Kito -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Wed, 5 Oct 2005 20:48:26 -0500 Brian Harring [EMAIL PROTECTED] wrote: | The sensible place to start experimenting is by adapting existing | ebuilds and tinkering with ebuild.sh, not by adding something which | may or may not end up being relevant to portage proper. | | Bluntly, what the hell do you think we're talking about here? In | case you haven't caught on, there *are* portage modifications that | have to go with it, meaning more then ebuild.sh. And you don't have a clue what said modifications really are until after you solve the ebuild side of things. The correct way to solve the problem is as follows: 1. Properly define what you are trying to solve from an end result perspective. 2. Properly define and provide substantial examples of how this can be done sanely through ebuilds. 3. Work out how this applies to portage. 4. Make sensible small revisions to 2. and 1. as necessary based upon any problems encountered in 3. The wrong way is as follows: 1. Jump in with some portage code which does something random. 2. Come up with a badly thought out incomplete requirements list. 3. Start hacking ebuilds into an even worse mess to accommodate earlier screwups. And for the sake of completeness, the other wrong way which isn't being taken this time is: 1. Come up with some buzzwords. 2. ??? 3. Profit! | Regardless, I'll backport haubi's patch to stable if anyone is after | screwing with it, unless michael's has a version that applies cleanly | to .53_rc4. Enough dancing, would rather hand it off to those who | are interested, and see what they come up with rather then fencing | via email (and accomplishing nothing). *sniff* *sniff* Ah yes, the familiar smell of multilib, osx, genkernel and the original portage implementation. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpSjJb9MkVhc.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Wed, 5 Oct 2005 20:56:42 -0500 Kito [EMAIL PROTECTED] wrote: | Its not like this is unchartered territory... off the top o' | me head pkgsrc, DarwinPorts, openpkg, fink, written word, | autopackage, MINE, and SamHain have all tackled this in one way or | the other. All of these projects have their faults (duh? but then | again so does portage and the ebuild tree) but a few of them have | been quite successful despite their varying points of inherent | silliness. Sure. They work around it by having lots and lots of workaround code, not by solving the original problem. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpbIJpgq1dzl.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Oct 5, 2005, at 9:02 PM, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 20:56:42 -0500 Kito [EMAIL PROTECTED] wrote: | Its not like this is unchartered territory... off the top o' | me head pkgsrc, DarwinPorts, openpkg, fink, written word, | autopackage, MINE, and SamHain have all tackled this in one way or | the other. All of these projects have their faults (duh? but then | again so does portage and the ebuild tree) but a few of them have | been quite successful despite their varying points of inherent | silliness. Sure. They work around it by having lots and lots of workaround code, not by solving the original problem. Most of the workaround code I see in the few of these I'm acquainted with is in the various bootstrap mechanisms, and the general deficiency of the underlying PM, i.e. no sane package versioning scheme (ports like python24, gcc3,gcc4, etc.), no globally defined 'build opts'(read: use flags), and nowhere to store platform specific knowledge (profiles), so all that crap ends up being stuffed directly in their portfiles. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Thu, Oct 06, 2005 at 03:01:12AM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 20:48:26 -0500 Brian Harring [EMAIL PROTECTED] wrote: | The sensible place to start experimenting is by adapting existing | ebuilds and tinkering with ebuild.sh, not by adding something which | may or may not end up being relevant to portage proper. | | Bluntly, what the hell do you think we're talking about here? In | case you haven't caught on, there *are* portage modifications that | have to go with it, meaning more then ebuild.sh. snip lots of you're doing something I think is dumb/I don't agree/slams at pvdabeel/lv/others who have attempted things in the tree Clarification of two things. First- this is external, including the patch. So comparing it to attempts that were done in a live tree is a bit of intentional bullshit/rhetoric. The entire intention of this is to work it out, *outside* of the tree, something those involved know. You seem to be out of the loop, not surprising considering your attitude towards this whole attempt. Second- Not having a clue about what the full set of modifications are going to be until you solve the ebuild side of it is *exactly* why people have to jump in and actually test the damn thing. You can solve as much of it up front as you know will be an issue, testing will reveal the additional issues. Under your suggested route, nothing is accomplished (potentially the reason you're suggesting all issues up front be addressed regardless of whether or not if they'll actually _be_ issues). What you're offering as a proposed/sane route is a route that produces nothing due to the fact you think everything must be solved up front, regardless if it turns out to be an issue or not (let alone identifying everything that may or may not be an issue) . Get the basic portage support up, they iron out the base mods initially needed, and jump in and identify the bugs that crop up further. Essentially, lets see how well this actually works out, rather then listening to you run your mouth about how it's a bad idea whenever it comes up, and all of these things will be issues (/bin/sh usage isn't an issue for the initial test target of osx). Either way, they're doing the work, you aren't, and you really don't have *any* say over their efforts until they finalize a solution and bring it to *devs* (not just you) for merging into mainline. So bluntly, shut up and let those who you think are being retarded, be retarded. Discussions on this list regarding those attempts shouldn't be heckled unless you're contributing to those efforts (and I truly mean *contributing*, not trying to punch holes in embryonic efforts that are trying to get off the ground addressing the major issues up front). Regardless, your points (repeatedly restated in the varying forms) have been noted, and those who are interested have no reason to not move forward with ironing out an implementation, and testing it. I suggest you sit quietly and let them do their work, rather then riding their asses. You might be surprised at what they come up with. If/When they push for inclusion, the merits of their efforts their solution (and outstanding issues) will be evaluated then. Back off and let them do their work, it's not affecting you in anyway, so again, you really don't have any say in it till they push for mainline. So... yeah. I'll post the prefix support backport patch once it's done, few days I'd expect since there is a fair amount of autotooling to deal with also. Those interested, I suggest you chip in, whether to spite ciaran (good or bad reasons, doesn't matter, result does :), or to get this feature you want realized. ~harring pgpadtl900v4S.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Wed, 5 Oct 2005, Kito wrote: [snip] My first question would be how to identify ebuilds that respect ${prefix}? A separate profile/keyword seems wrong. ICANINSTALLTO was the best idea presented, but that implies it would be a list of known working prefixes, which seems unrealistic. What problem was ICANINSTALLTO intended to solve? IIRC, it was discussed on -dev in the context of vim plug-ins. Apart from vim plugins, has anyone found other problem packages? I'm wondering, would a constraint to the effect that certain deps of pkg foo must be on the same prefix as foo suffice for the vim plugin case? Or maybe that would work better if expressed, pkg blah can not satisfy a dep from any pkg on a different prefix. Such constraints would be possible to implement with a new file in the profile (say, package.local). -f Maybe it would be better to have portage error check that globally at the load_config stage against a list of known stupid prefixes, stupidprefixes=[/usr,/,/bin] etc. etc. --Kito -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Thu, Oct 06, 2005 at 02:14:32PM +1000, Finn Thain wrote: On Wed, 5 Oct 2005, Kito wrote: [snip] My first question would be how to identify ebuilds that respect ${prefix}? A separate profile/keyword seems wrong. ICANINSTALLTO was the best idea presented, but that implies it would be a list of known working prefixes, which seems unrealistic. What problem was ICANINSTALLTO intended to solve? IIRC, it was discussed on -dev in the context of vim plug-ins. Apart from vim plugins, has anyone found other problem packages? I'm wondering, would a constraint to the effect that certain deps of pkg foo must be on the same prefix as foo suffice for the vim plugin case? Or maybe that would work better if expressed, pkg blah can not satisfy a dep from any pkg on a different prefix. Such constraints would be possible to implement with a new file in the profile (say, package.local). That gets into more of ciaran's HOME installation target feature. Current form for global prefix offset is DOMAIN=root offset , with offset == prefix offset. If an ebuild doesn't have DOMAIN=offset, and you're doing a prefix offset, it's unusable. No question of can I use a dep from another prefix, with prefix offset you're doing the deps full in an offset. As stated earlier in this mess of a thread, HOME crap is being left to those who want it, it'll be implemented by those who want it after global prefix is ironed out (if it is accepted also). ~harring pgpEHAG0zrtZw.pgp Description: PGP signature