[gentoo-portage-dev] Questions about CVS locations and GID...

[gentoo-portage-dev] Questions about CVS locations and GID...

[m h]

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...

-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 448 bytes --]

On Wed, 5 Oct 2005 11:35:18 -0700 m h <sesquile@gmail.com> 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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Alec Joseph Warner]

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...

[m h]

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 <warnera6@egr.msu.edu> 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...

[Alec Joseph Warner]

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 <warnera6@egr.msu.edu> 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...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 3257 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[m h]

On 10/5/05, Brian Harring <ferringb@gentoo.org> 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.

> > >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.
>

thanks for the pointer

> > >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.

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....)

>
> > 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.
>

Yes, I waded through a bit of that discussion...  I really don't care
about the HOME issue (I'm not saying that others can't ;)).  My take
is that an app can do what it wants, and if it puts something in HOME
so be it.  In my case, there usually won't be two versions of an app
(so it shouldn't be an issue), though I realize others have differenct
use cases, and expectations.

> 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.
>

Sorry, I don't know what EAPI means....

> 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.

Sounds good to me....

>
> 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)


> 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
>

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?

Sorry for all the questions, again I'm not looking to start a flame
war, I'm looking for some features and like what gentoo has done and
what can be done with it.  I'm not trying to work against or outside
what the mainline developers are doing....

-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 4502 bytes --]

On Wed, Oct 05, 2005 at 01:48:03PM -0700, m h wrote:
> On 10/5/05, Brian Harring <ferringb@gentoo.org> 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 :)

> 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 :)


> > 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.
> >
> 
> Sorry, I don't know what EAPI means....
Ebuild API.
Stable portage's ebuild env, funcs available, etc, is EAPI=0.

Think of it as specifying the lib you want; the ebuild.sh specific 
changes that will be in the rewrite (elib, src_configure phase 
addition, deprived setup phase) would be EAPI=1

Basically, it gives us a way to introduce changes for how ebuilds are 
called/executed, what they expect from the env, without breaking 
things.  It also gives us a way to break compatibility between EAPI 
versions; as long as the metadata exported is correct for the ebuild's 
EAPI and we're still doing a declarative design for calling into the 
ebuild, we can basically do whatever we want.

> > 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.

Baby steps. :)

> > 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
> >
> 
> 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.


> Sorry for all the questions, again I'm not looking to start a flame
> war, I'm looking for some features and like what gentoo has done and
> what can be done with it.  I'm not trying to work against or outside
> what the mainline developers are doing....

Wouldn't worry about it, my initial response was phrased strongly due 
to the fact whenever implementing global prefix is brought up the 
screams against it start prior to even being able to iron out, or 
discuss it.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[m h]

On 10/5/05, Brian Harring <ferringb@gentoo.org> wrote:
> On Wed, Oct 05, 2005 at 01:48:03PM -0700, m h wrote:
> > On 10/5/05, Brian Harring <ferringb@gentoo.org> 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...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[m h]

On 10/5/05, Brian Harring <ferringb@gentoo.org> wrote:
> 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.
>

Great, so on that note, since Haubi's work is based on portage 2.1,
can anyone point me to the cvs repository?  (Or are they all moved to
svn?)

-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]

On Wed, Oct 05, 2005 at 04:01:54PM -0700, m h wrote:
> On 10/5/05, Brian Harring <ferringb@gentoo.org> wrote:
> > 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.
> >
> 
> Great, so on that note, since Haubi's work is based on portage 2.1,
> can anyone point me to the cvs repository?  (Or are they all moved to
> svn?)
svn co svn://twobit.net/portage/main/trunk # <-- 2.1 branch
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

On Wed, 5 Oct 2005 15:24:29 -0500 Brian Harring <ferringb@gentoo.org>
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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

On Wed, Oct 05, 2005 at 09:57:03PM +0100, Ciaran McCreesh wrote:
> On Wed, 5 Oct 2005 15:24:29 -0500 Brian Harring <ferringb@gentoo.org>
> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

On Wed, 5 Oct 2005 16:13:06 -0500 Brian Harring <ferringb@gentoo.org>
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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

On Wed, Oct 05, 2005 at 11:31:32PM +0100, Ciaran McCreesh wrote:
> On Wed, 5 Oct 2005 16:13:06 -0500 Brian Harring <ferringb@gentoo.org>
> 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



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

On Wed, 5 Oct 2005 18:00:12 -0500 Brian Harring <ferringb@gentoo.org>
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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

On Thu, Oct 06, 2005 at 12:14:30AM +0100, Ciaran McCreesh wrote:
> On Wed, 5 Oct 2005 18:00:12 -0500 Brian Harring <ferringb@gentoo.org>
> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

On Wed, 5 Oct 2005 18:22:37 -0500 Brian Harring <ferringb@gentoo.org>
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
| > <ferringb@gentoo.org>
| > 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.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

On Thu, Oct 06, 2005 at 12:38:35AM +0100, Ciaran McCreesh wrote:
> On Wed, 5 Oct 2005 18:22:37 -0500 Brian Harring <ferringb@gentoo.org>
> 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
> | > <ferringb@gentoo.org>
> | > 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

On Wed, 5 Oct 2005 18:40:46 -0500 Brian Harring <ferringb@gentoo.org>
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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

On Thu, Oct 06, 2005 at 01:13:53AM +0100, Ciaran McCreesh wrote:
> On Wed, 5 Oct 2005 18:40:46 -0500 Brian Harring <ferringb@gentoo.org>
> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

On Wed, 5 Oct 2005 20:01:34 -0500 Brian Harring <ferringb@gentoo.org>
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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]

On Thu, Oct 06, 2005 at 02:07:32AM +0100, Ciaran McCreesh wrote:
> On Wed, 5 Oct 2005 20:01:34 -0500 Brian Harring <ferringb@gentoo.org>
> 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.

And how are you going to verify autoconf works perfectly without 
testing it?

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*?

You're not offering any good reasons why people can't jump in and 
experiment with it despite the vaunted "plan it out first".  Gurantee 
attempting prefix offset, things will *always* be missed for handling 
all issues if you're just planning it.

Basically, I'm not seeing what point you're making beyond the fact 
there is work that's going to have to be done from the ebuild side of 
things (work you won't be able to predict I'd posit).

Last time around, prefix was ixnayed due to the fact there was work.  
People want it, and are willing to do the legwork.

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.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]

On Wed, 5 Oct 2005 20:17:40 -0500 Brian Harring <ferringb@gentoo.org>
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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2548 bytes --]

On Thu, Oct 06, 2005 at 02:23:47AM +0100, Ciaran McCreesh wrote:
> On Wed, 5 Oct 2005 20:17:40 -0500 Brian Harring <ferringb@gentoo.org>
> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

On Wed, 5 Oct 2005 20:32:20 -0500 Brian Harring <ferringb@gentoo.org>
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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]

On Thu, Oct 06, 2005 at 02:40:58AM +0100, Ciaran McCreesh wrote:
> On Wed, 5 Oct 2005 20:32:20 -0500 Brian Harring <ferringb@gentoo.org>
> 
> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]

On Wed, 5 Oct 2005 20:48:26 -0500 Brian Harring <ferringb@gentoo.org>
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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 3843 bytes --]

On Thu, Oct 06, 2005 at 03:01:12AM +0100, Ciaran McCreesh wrote:
> On Wed, 5 Oct 2005 20:48:26 -0500 Brian Harring <ferringb@gentoo.org>
> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1521 bytes --]

On Wed, 5 Oct 2005 21:39:49 -0500 Brian Harring <ferringb@gentoo.org>
wrote:
| 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).

Pfff. By contributing to the design by showing what *won't* work, I'm
saving a heck of a lot of wasted man hours that will otherwise be spent
writing a non-working solution.

A contribution of code is worthless if the code is completely wrong, no
matter how much effort was spent producing it.

But then, we all know how this goes. When the code's 'done', it gets
merged, and then you start claiming "If you had any issues with it you
should have brought them up at the design stage. It's too late now!".
So really, it's a no win situation. Point out gaping design flaws at the
start and you're accused of shooting holes in things that don't exist
yet. Point out gaping design flaws when it's first merged and you're
accused of shooting holes in things upon which people have spent lots
of time. Point out gaping design flaws after it goes live and you're
told it's too late.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Jason Stubbs]

On Thursday 06 October 2005 20:51, Ciaran McCreesh wrote:
> On Wed, 5 Oct 2005 21:39:49 -0500 Brian Harring <ferringb@gentoo.org>
>
> wrote:
> | 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).
>
> Pfff. By contributing to the design by showing what *won't* work, I'm
> saving a heck of a lot of wasted man hours that will otherwise be spent
> writing a non-working solution.

I must admit that I've simply ignored this thread for the most part, but 
glancing through your emails I can't find any list of reasons why it won't 
work. I can only find statements that it won't work and that the creative 
process should follow a different path (=plan everything first).

--
Jason Stubbs
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Alec Warner]

Ciaran McCreesh wrote:

>On Wed, 5 Oct 2005 21:39:49 -0500 Brian Harring <ferringb@gentoo.org>
>wrote:
>| 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).
>
>Pfff. By contributing to the design by showing what *won't* work, I'm
>saving a heck of a lot of wasted man hours that will otherwise be spent
>writing a non-working solution.
>
>A contribution of code is worthless if the code is completely wrong, no
>matter how much effort was spent producing it.
>
>But then, we all know how this goes. When the code's 'done', it gets
>merged, and then you start claiming "If you had any issues with it you
>should have brought them up at the design stage. It's too late now!".
>So really, it's a no win situation. Point out gaping design flaws at the
>start and you're accused of shooting holes in things that don't exist
>yet. Point out gaping design flaws when it's first merged and you're
>accused of shooting holes in things upon which people have spent lots
>of time. Point out gaping design flaws after it goes live and you're
>told it's too late.
>
>  
>
Then I suggest you file this e-mail away and when the time comes that 
the code is to be merged and it sucks ( and by sucks I mean more than 
"it doesn't meet Ciaran's software engineering standards" ) you can 
waive the mail in everyone's face.  No project, specs or not, is ever 
written right the first time.  At the very least someone can take his 
code and improve on it in the future.
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

On Thu, 06 Oct 2005 09:07:12 -0400 Alec Warner <warnera6@egr.msu.edu>
wrote:
| Then I suggest you file this e-mail away and when the time comes that 
| the code is to be merged and it sucks ( and by sucks I mean more than 
| "it doesn't meet Ciaran's software engineering standards" ) you can 
| waive the mail in everyone's face.  No project, specs or not, is ever 
| written right the first time.  At the very least someone can take his 
| code and improve on it in the future.

Yeah, right, because saying "I told you so" after the shit hits the fan
is ever so helpful. Right.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2018 bytes --]

On Thu, Oct 06, 2005 at 07:29:12PM +0100, Ciaran McCreesh wrote:
> On Thu, 06 Oct 2005 09:07:12 -0400 Alec Warner <warnera6@egr.msu.edu>
> wrote:
> | Then I suggest you file this e-mail away and when the time comes that 
> | the code is to be merged and it sucks ( and by sucks I mean more than 
> | "it doesn't meet Ciaran's software engineering standards" ) you can 
> | waive the mail in everyone's face.  No project, specs or not, is ever 
> | written right the first time.  At the very least someone can take his 
> | code and improve on it in the future.
> 
> Yeah, right, because saying "I told you so" after the shit hits the fan
> is ever so helpful. Right.

What's stated above, and what this thread has come down to is that 
you're putting a lot of reqs and pointing at whatever roadblock you 
can for anyone who attempts it.  Kudos, although bluntly, talk is 
cheap.

You're not chipping in any way, you're fitting the exact definition of 
drobbin's "freak"
http://www.gentoo.org/doc/en/articles/making-the-distro-p1.xml
in how you're interacting with those attempting to pull this off (and 
I'm not even remotely commenting on your flaming of those merely 
asking questions).

Produce a patch and maybe people will listen to you, otherwise those 
of us who are tired of listening to others state how it should be done 
(but do nothing but talk), are going to jump in and do it, addressing 
the issues thus pointed out.

In other words, their really is no point in debating people attempting 
it. They're going too, and as I made pretty bluntly clear, the only say 
you've got on this is as a member of the dev community when/if they 
push for it to go mainline.

Kind of hard to block it when nothing has been produced after all.

Regardless, this list doesn't have flamewars, and I'd thank 
all participants to kindly back off (and yes, I'm being a damn 
hypocrite in stating it).

If people are up for the continuing pissing match, take it private.  
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

On Thu, 6 Oct 2005 13:42:55 -0500 Brian Harring <ferringb@gentoo.org>
wrote:
| What's stated above, and what this thread has come down to is that 
| you're putting a lot of reqs and pointing at whatever roadblock you 
| can for anyone who attempts it.  Kudos, although bluntly, talk is 
| cheap.

Bah. Not roadblocks, basic design requirements.

| Produce a patch and maybe people will listen to you, otherwise those 
| of us who are tired of listening to others state how it should be
| done (but do nothing but talk), are going to jump in and do it,
| addressing the issues thus pointed out.

Unlike some, I don't pretend to know enough about the design part of
this to even consider working on a patch. Code that does the wrong
thing is at best worthless.

| In other words, their really is no point in debating people
| attempting it. They're going too, and as I made pretty bluntly clear,
| the only say you've got on this is as a member of the dev community
| when/if they push for it to go mainline.

...at which point, you will claim "the work is already done, so it's
too late to block this now".

| If people are up for the continuing pissing match, take it private.  

"I'm not hearing what I want to hear, so I will repeatedly throw out
lots of ad hominem attacks and wild accusations rather than address the
issues at hand."

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Kito]

On Oct 5, 2005, at 7:13 PM, Ciaran McCreesh wrote:

> On Wed, 5 Oct 2005 18:40:46 -0500 Brian Harring <ferringb@gentoo.org>
> 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...

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

On Wed, 5 Oct 2005 20:56:42 -0500 Kito <kito@gentoo.org> 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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Kito]

On Oct 5, 2005, at 9:02 PM, Ciaran McCreesh wrote:

> On Wed, 5 Oct 2005 20:56:42 -0500 Kito <kito@gentoo.org> 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...

[Alec Warner]

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 <ferringb@gentoo.org>
>>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...

[m h]

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 <warnera6@egr.msu.edu> 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 <ferringb@gentoo.org>
> >>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...

[Alec Warner]

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 <warnera6@egr.msu.edu> 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 <ferringb@gentoo.org>
>>>>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...

[Kito]

On Oct 5, 2005, at 3:57 PM, Ciaran McCreesh wrote:

> On Wed, 5 Oct 2005 15:24:29 -0500 Brian Harring <ferringb@gentoo.org>
> 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...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

On Wed, 5 Oct 2005 16:16:06 -0500 Kito <kito@gentoo.org> 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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

On Wed, Oct 05, 2005 at 11:29:56PM +0100, Ciaran McCreesh wrote:
> On Wed, 5 Oct 2005 16:16:06 -0500 Kito <kito@gentoo.org> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

On Wed, 5 Oct 2005 17:53:36 -0500 Brian Harring <ferringb@gentoo.org>
wrote:
| On Wed, Oct 05, 2005 at 11:29:56PM +0100, Ciaran McCreesh wrote:
| > On Wed, 5 Oct 2005 16:16:06 -0500 Kito <kito@gentoo.org> 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.

Oh come off it. You claim that no dev has made this naive demand when
at least one quite clearly has on several occasions. All three of my
points are entirely relevant to the discussion, since every other time
this has come up at least one said mistakes has been made.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]

On Thu, Oct 06, 2005 at 12:03:18AM +0100, Ciaran McCreesh wrote:
> On Wed, 5 Oct 2005 17:53:36 -0500 Brian Harring <ferringb@gentoo.org>
> wrote:
> | On Wed, Oct 05, 2005 at 11:29:56PM +0100, Ciaran McCreesh wrote:
> | > On Wed, 5 Oct 2005 16:16:06 -0500 Kito <kito@gentoo.org> 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.
> 
> Oh come off it. You claim that no dev has made this naive demand when
> at least one quite clearly has on several occasions. All three of my
> points are entirely relevant to the discussion, since every other time
> this has come up at least one said mistakes has been made.

Again, do you see anyone here claiming all are simple?  It's the same 
points made last time around, those who want it do the work, it's 
going to be bumpy and will require work, but those who want it are the 
ones who have to do it.

Bluntly, stick to the discussion of prefix, or go elsewhere.  Bash 
pvdabeel if you like but sure as hell not on this list since no one 
cares, further since it's not relevant to the _current_ discussion, 
where people are actually attempting to pull this off.

If as you posit, it's not been discussed/planned properly, I suggest 
you stick to contributing to the discussion and planning of it.  The 
alternative is that people get fed up with the the ancillary bullshit, 
and they implement it themselves (which I'm sure you would dislike).
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Finn Thain]

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...

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]