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

[Ciaran McCreesh]

On Wed, 5 Oct 2005 21:39:49 -0500 Brian Harring [EMAIL PROTECTED]
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



pgp0oXvLP1axK.pgp
Description: PGP signature

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 [EMAIL PROTECTED]

 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 [EMAIL PROTECTED]
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...

[Brian Harring]

On Thu, Oct 06, 2005 at 07:29:12PM +0100, Ciaran McCreesh wrote:
 On Thu, 06 Oct 2005 09:07:12 -0400 Alec Warner [EMAIL PROTECTED]
 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


pgphwQR49pGmo.pgp
Description: PGP signature

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

[Ciaran McCreesh]

On Thu, 6 Oct 2005 13:42:55 -0500 Brian Harring [EMAIL PROTECTED]
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



pgpdvxGwcbXrq.pgp
Description: PGP signature

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

[Ciaran McCreesh]

On Wed, 5 Oct 2005 11:35:18 -0700 m h [EMAIL PROTECTED] wrote:
| I'm working on trying to get prefixed installs working.

You might want to start with a proper (not content-free like the last
two attempts) requirements spec and design before you jump in with the
code.

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



pgpkrE2gJ3tDk.pgp
Description: PGP signature

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

[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 [EMAIL PROTECTED] wrote:


 m h wrote:
  Hey Folks-
 
  I'm working on trying to get prefixed installs working.  (As such, I'm
  using some code kindly modified by Michael Haubenwallner. )  I'm now
  in python code (portage) and would like to compare what I have with
  gentoo proper.
  Is this the location of the latest up to date portage code (in CVS, I
  realized devs might have more up to date code on their boxes):
  http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/pym/?root=gentoo-src
 
  I looked through the dev documentation but couldn't find anywhere
  where it stated the actual location of the code in CVS.  Any pointers
  would be great.
 
  thanks,
  matt
 
  ps.
  The issue I found is with pym/cache/fs_template.py.  If I'm running as
  root (GID = 0) then this fails:
 
  def __init__(self, label, auxdbkeys, basepath=None, gid=-1,
  perms=0664, **config):
 throws InitializationError if needs args aren't 
  specified
 if not gid:
 raise
  cache_errors.InitializationError(self.__class__, must specify gid!)
 
  Shouldn't the logic be if gid != -1?  I don't have access to a
  gentoo proper box right now...
 

 I thought that part of brian's domain stuff in Savior was to cover this.
   In either case no one should be writing any real code at this point
 since no one has agreed on any sane way to pull this off.  There needs
 to be plenty of healthy discussion the pro's and con's of how things
 should be done in regards to *-prefix.

 In conclusion, if you think this will be 'easy', think again ;)

 PS.  However starting discussion on how exactly this would work might be
 a nice thing to do ;)
 --
 gentoo-portage-dev@gentoo.org mailing list



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

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

[Brian Harring]

Yay, time for another flame war (just what I'd love to spend my time 
on).

On Wed, Oct 05, 2005 at 04:06:47PM -0400, Alec Joseph Warner wrote:
 Hey Folks-
 
 I'm working on trying to get prefixed installs working.  (As such, I'm
 using some code kindly modified by Michael Haubenwallner. )  I'm now
 in python code (portage) and would like to compare what I have with
 gentoo proper.
 Is this the location of the latest up to date portage code (in CVS, I
 realized devs might have more up to date code on their boxes):
 http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/pym/?root=gentoo-src

 I looked through the dev documentation but couldn't find anywhere
 where it stated the actual location of the code in CVS.  Any pointers
 would be great.
We've moved to svn, which will be available via viewcvs shortly.  
Anonymous svn is available if you poke your head into irc.freenode.net 
#gentoo-portage, and pull it from the /topic.

 The issue I found is with pym/cache/fs_template.py.  If I'm running as
 root (GID = 0) then this fails:
 
 def __init__(self, label, auxdbkeys, basepath=None, gid=-1,
 perms=0664, **config):
throws InitializationError if needs args aren't 
specified
if not gid:
raise
 cache_errors.InitializationError(self.__class__, must specify gid!)
Judging by location, that's 2.1.

The extra opts are directly changable via configuration under the 
rewrite's code, so setting gid isn't hard.

 Shouldn't the logic be if gid != -1?  I don't have access to a
 gentoo proper box right now...
Yah. 
That said that code's been corrected under the rewrite.

 I thought that part of brian's domain stuff in Savior was to cover this. 
  In either case no one should be writing any real code at this point 
 since no one has agreed on any sane way to pull this off.  There needs 
 to be plenty of healthy discussion the pro's and con's of how things 
 should be done in regards to *-prefix.

There was plenty of discussion about it last time around.  It got sunk 
due to the fact that ciaran was a bit hell bent on having HOME 
integrated into it.  All or none, was effectively the issue.

The current line of thought on it is global prefix going in as an addition 
to an EAPI release, _strictly_ global prefix.  The home crap (interdomain 
deps, querying information/location of package X) being a later release.

Why?  Doing prefix is hard.  Doing prefix + home is harder.  A global 
offset for PREFIX is going to require a fair amount of work.  Tacking 
home into it (something that a global offset does _not_ require) is 
sadling a requested feature with a lesser feature.

Do 'em seperate.  Those who want interdomain, they can do the work.  
Those who want global offset, they can do that chunk.

To head off the it's not going to work for vim-*, yah, you'll be 
boned and have to install duplicate vim-* into the global prefix.
Bluntly, either you dive in and start wading through the problems 
(fixing them as you go), or you sit back listening to how it's never 
going to work (thus accomplishing nothing).
~harring


pgpNB0H1f7KlS.pgp
Description: PGP signature

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

[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 [EMAIL PROTECTED] wrote:



m h wrote:


Hey Folks-

I'm working on trying to get prefixed installs working.  (As such, I'm
using some code kindly modified by Michael Haubenwallner. )  I'm now
in python code (portage) and would like to compare what I have with
gentoo proper.
Is this the location of the latest up to date portage code (in CVS, I
realized devs might have more up to date code on their boxes):
http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/pym/?root=gentoo-src

I looked through the dev documentation but couldn't find anywhere
where it stated the actual location of the code in CVS.  Any pointers
would be great.

thanks,
matt

ps.
The issue I found is with pym/cache/fs_template.py.  If I'm running as
root (GID = 0) then this fails:

   def __init__(self, label, auxdbkeys, basepath=None, gid=-1,
perms=0664, **config):
  throws InitializationError if needs args aren't specified
  if not gid:
  raise
cache_errors.InitializationError(self.__class__, must specify gid!)

Shouldn't the logic be if gid != -1?  I don't have access to a
gentoo proper box right now...



I thought that part of brian's domain stuff in Savior was to cover this.
 In either case no one should be writing any real code at this point
since no one has agreed on any sane way to pull this off.  There needs
to be plenty of healthy discussion the pro's and con's of how things
should be done in regards to *-prefix.

In conclusion, if you think this will be 'easy', think again ;)

PS.  However starting discussion on how exactly this would work might be
a nice thing to do ;)
--
gentoo-portage-dev@gentoo.org mailing list






* Now talking on #gentoo-portage
* Topic for #gentoo-portage is: 2.0.53_rc3 released; please test || 
emerge development only; ebuild dev questions go to #gentoo-dev-help and 
usage questions go to #gentoo || anonsvn access: svn co 
svn://twobit.net/portage/, rewrite is at main/branches/savior, 2.1 is at 
main/trunk, 2.0 is at main/branches/2.0 and sandbox is at path-sandbox/trunk


IRC is your friend here ;)  In this case you probably want the rewrite, 
which is from what I recall, a complete rewrite...so nothing of Haubi's 
is in it.  Brian will definately know more there than myself, I haven't 
touched it in quite some time, and I doubt RL will let me for a bit :P

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

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

[Ciaran McCreesh]

On Wed, 5 Oct 2005 15:24:29 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| To head off the it's not going to work for vim-*, yah, you'll be 
| boned and have to install duplicate vim-* into the global prefix.
| Bluntly, either you dive in and start wading through the problems 
| (fixing them as you go), or you sit back listening to how it's never 
| going to work (thus accomplishing nothing).

It can be made to work, so long as you don't a) jump in without proper
planning, b) assume that you'll not have to modify ebuilds and c)
demand that as soon as it's available, it works for all ebuilds.

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



pgpDq8Dkk8Yjv.pgp
Description: PGP signature

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

[Brian Harring]

On Wed, Oct 05, 2005 at 09:57:03PM +0100, Ciaran McCreesh wrote:
 On Wed, 5 Oct 2005 15:24:29 -0500 Brian Harring [EMAIL PROTECTED]
 wrote:
 | To head off the it's not going to work for vim-*, yah, you'll be 
 | boned and have to install duplicate vim-* into the global prefix.
 | Bluntly, either you dive in and start wading through the problems 
 | (fixing them as you go), or you sit back listening to how it's never 
 | going to work (thus accomplishing nothing).
 
 It can be made to work, so long as you don't a) jump in without proper
 planning, b) assume that you'll not have to modify ebuilds and c)
 demand that as soon as it's available, it works for all ebuilds.
I'd point out that the last time prefix was brought up, all of those 
points were addressed.

A) would like to hear what you think is required planning wise 
compared to the previous haubi prototype patch.

B) Modifying the ebuilds is required, although modifying the underlying 
base defaults does cover a good swath of ebuilds

C) See previous comments from last round of this stating those who 
want it, have to do the work.

~harring


pgpjCoEJ44DaB.pgp
Description: PGP signature

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

[Kito]

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


On Wed, 5 Oct 2005 15:24:29 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| To head off the it's not going to work for vim-*, yah, you'll be
| boned and have to install duplicate vim-* into the global prefix.
| Bluntly, either you dive in and start wading through the problems
| (fixing them as you go), or you sit back listening to how it's never
| going to work (thus accomplishing nothing).

It can be made to work, so long as you don't
a) jump in without proper planning


Well, then lets plan, not flame.


b) assume that you'll not have to modify ebuilds


I don't think anyone(devs) has made this naive assumption have they?


and c)
demand that as soon as it's available, it works for all ebuilds.


I don't think anyone(devs) has made this naive demand have they?


So, lets address a) and c) since b) is a given.

My first question would be how to identify ebuilds that respect $ 
{prefix}?


A separate profile/keyword seems wrong.

ICANINSTALLTO was the best idea presented, but that implies it would  
be a list of known working prefixes, which seems unrealistic. Maybe  
it would be better to have portage error check that globally at the  
load_config stage against a list of known stupid prefixes,  
stupidprefixes=[/usr,/,/bin] etc. etc.


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

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

[Brian Harring]

On Wed, Oct 05, 2005 at 04:16:06PM -0500, Kito wrote:
 My first question would be how to identify ebuilds that respect $ 
 {prefix}?
 
 A separate profile/keyword seems wrong.
Agreed.

 
 ICANINSTALLTO was the best idea presented, but that implies it would  
 be a list of known working prefixes, which seems unrealistic.
DOMAIN is a saner name imo.  Aside from that, listing every potential 
target (/usr/bin, $HOME/bin fex) is whacky and getting into the HOME 
stuff that comes after.

I would suggest root, and offset as the initial targets.
root would be implicit if DOMAIN isn't defined, and references / as 
the prefix.  offset is just as it sounds, a root offset, everything 
from that tree installed at an offset.

 Maybe  
 it would be better to have portage error check that globally at the  
 load_config stage against a list of known stupid prefixes,  
 stupidprefixes=[/usr,/,/bin] etc. etc.
Bit beyond the ken of this discussion, but yah, agreed.
~harring


pgpon9LigF1m7.pgp
Description: PGP signature

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

[m h]

On 10/5/05, Brian Harring [EMAIL PROTECTED] wrote:
 On Wed, Oct 05, 2005 at 01:48:03PM -0700, m h wrote:
  On 10/5/05, Brian Harring [EMAIL PROTECTED] wrote:
   Yay, time for another flame war (just what I'd love to spend my time
   on).
 
  Sorry, I'm really not trying to kindle any flames here.
 Heh, you're not, I'm just mildly pissy due to recurrent flamewars :)

In which case I'm sorry to be the bearer or recurrent touchy subjects ;)


  So, on the topic of rewrite.  Does there happen to be any testcases
  for portage?  Unittests, etc?  I'd be nice to verify that rewrite
  behaves properly (well, actually I want testcases for selfish reasons,
  so I don't break code if I change anything)
 Niadda.

 Would love it if someone stepped up on that, since I don't
 particularly have the time right now :)

Can possibly help out on that, see below...


   Do 'em seperate.  Those who want interdomain, they can do the work.
   Those who want global offset, they can do that chunk.
 
  I understand the interdomain stuff to be that prefixed packages can
  depend on packages outside of their prefix?  If so, I don't want this
  feature.  I want an isolated sandbox.  (Again, I realize others have
  different needs)
 Pretty much.  Best description is dependencies between root's.
 Global prefix (for osx) would either
 A) have a vdb for that prefix that represented the package.provided
nodes
 B) have a domain for root=/, and do interdomain.

 A is likely route due to it being a helluva lot simpler; B is
 better/cleaner (imo), but it requires more work.


Hmmm, I'm not clear yet on the value of interdomain, but I'm sure
someone will enlighten me along the way...


 
  So, I figure I'm sortof diving in with Haubi's code (against the
  advice of those wanted a complete spec) since I think my needs seem to
  be the most minimum subset of what others want in this feature.  I
  think it's a good way to help me understand the innards of portage
  (though the code is pretty spaghetti right now).  I presume you think
  I should start with rewrite as a base?  What is the current status
  of rewrite?
 Rewrite's code is a heck of a lot cleaner; oop based for starters :)
 There is some nastyness, but it's encapsulated, and pretty much
 required.

 Current state of it is that I'm atm stuck on plugin code, and a slight
 change to the config handling code.

 Building/fetching are done, full immutable ebuild tree and vdb are
 done, immutable binpkg repository is done sans a package class.

 The mutable thing is basically querying the db; for vdb and binpkg,
 they need to be modifiable, able to add a package to the repository
 (merging).  I'm working on that atm.

 Jason's doing resolver work, state of that I can't comment on (that's
 his thing).

 ebuild*sh side of it's already done- if you were looking to test out
 prefix building (experiment) I'd probably start there.


OK, so since I have a deadline (end of next week) I'd like to have a
simple prototype working.  IE me running apache on FC4 with portage. 
If I can do that then it's very likely that I'll be able to devote a
bit of time towards working on this (where this could be rewrite) (bug
fixes, polishing it up, unittests, etc).  On that note, I need to know
what the timeframe for rewrite is.  If it's to a state where I can
work with it then maybe I should try and start from there.  But I'm
assumming it will be easier/quicker to get haubi's stuff working.

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

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

[Brian Harring]

On Wed, Oct 05, 2005 at 02:52:59PM -0700, m h wrote:
 Hmmm, I'm not clear yet on the value of interdomain, but I'm sure
 someone will enlighten me along the way...
interdomain would be how ciaran's HOME request would be pulled off; 
user's 'domain', configuration settings + prefix offset would try to 
satisfy deps from the global domain '/'.  When it can't, would resort 
to installing to the user's domain, assuming the ebuild is capable of 
it.

 OK, so since I have a deadline (end of next week) I'd like to have a
 simple prototype working.  IE me running apache on FC4 with portage. 
 If I can do that then it's very likely that I'll be able to devote a
 bit of time towards working on this (where this could be rewrite) (bug
 fixes, polishing it up, unittests, etc).  On that note, I need to know
 what the timeframe for rewrite is.  If it's to a state where I can
 work with it then maybe I should try and start from there.  But I'm
 assumming it will be easier/quicker to get haubi's stuff working.
Haubi's is what I'd recommend.
Rewrite isn't anywhere near that sort of timeline.

I'd also note realistically pulling it off within 10 days might be 
tricky, due to the fact it requires ebuild modifications plus dusting 
off and updating haubi's patch, along with buttload of testing.

Or I'm just slow at implementing stuff. :)
~harring


pgp7j0hS9Ee6H.pgp
Description: PGP signature

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

[Ciaran McCreesh]

On Wed, 5 Oct 2005 16:16:06 -0500 Kito [EMAIL PROTECTED] wrote:
|  b) assume that you'll not have to modify ebuilds
| 
| I don't think anyone(devs) has made this naive assumption have they?

pvdabeel has for pathspec.

|  and c)
|  demand that as soon as it's available, it works for all ebuilds.
| 
| I don't think anyone(devs) has made this naive demand have they?

pvdabeel has for pathspec.

| ICANINSTALLTO was the best idea presented, but that implies it would  
| be a list of known working prefixes, which seems unrealistic. Maybe  
| it would be better to have portage error check that globally at the  
| load_config stage against a list of known stupid prefixes,  
| stupidprefixes=[/usr,/,/bin] etc. etc.

The plan was to have ICANINSTALLTO=root home prefixed or somesuch.
The name isn't particularly clear on that...

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



pgp6Nbtw6j315.pgp
Description: PGP signature

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

[Ciaran McCreesh]

On Wed, 5 Oct 2005 16:13:06 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| A) would like to hear what you think is required planning wise 
| compared to the previous haubi prototype patch.

There has been no serious discussion on how *ebuilds* will use the
prefix system. Hacking econf and expecting PREFIX to be sufficient is
naive from a tree-perspective.

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



pgprvYY2wTOts.pgp
Description: PGP signature

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

[Brian Harring]

On Wed, Oct 05, 2005 at 11:29:56PM +0100, Ciaran McCreesh wrote:
 On Wed, 5 Oct 2005 16:16:06 -0500 Kito [EMAIL PROTECTED] wrote:
 |  b) assume that you'll not have to modify ebuilds
 | 
 | I don't think anyone(devs) has made this naive assumption have they?
 
 pvdabeel has for pathspec.
 
 |  and c)
 |  demand that as soon as it's available, it works for all ebuilds.
 | 
 | I don't think anyone(devs) has made this naive demand have they?
 
 pvdabeel has for pathspec.

You're not talking to pvdabeel right now, so kindly be quiet about 
him.

Further, don't argue the dev point, no one cares- we're discussing 
prefix, not getting pulled into tangents of pathspec nor slams at 
other devs.


 | ICANINSTALLTO was the best idea presented, but that implies it would  
 | be a list of known working prefixes, which seems unrealistic. Maybe  
 | it would be better to have portage error check that globally at the  
 | load_config stage against a list of known stupid prefixes,  
 | stupidprefixes=[/usr,/,/bin] etc. etc.
 
 The plan was to have ICANINSTALLTO=root home prefixed or somesuch.
 The name isn't particularly clear on that...

See email naming it as domain.  Home being a later target; not sure 
about prefixed, but it's as good of a name as any other (arbitrary, in 
other words).
~harring


pgpdiKyxShUiG.pgp
Description: PGP signature

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

[Ciaran McCreesh]

On Wed, 5 Oct 2005 18:00:12 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| Beyond that, there is the shebang issue which can be addresses via a 
| combination of automated scans/fixes, and fixing bugs as it's hit.  
| Hardcoded vars in scripts for the path to a binary are an issue also, 
| although again, scans can be done to at least check for it.

This one's a far bigger issue than might be initially obvious. It would
involve rewriting a whole load of autotools innards...

| Leaves mangling the build process so that the build framework of the 
| package uses the prefix offset files, rather then / .  For c/c++ 
| source, usual trick from fink afaik involves a mangling of cflags
| with -I tacked in.  Kinda ugly, although I'd expect there is a better 
| route.

Again, autoconf tinkering.

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



pgpnQhicXqEDx.pgp
Description: PGP signature

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

[Brian Harring]

On Thu, Oct 06, 2005 at 12:14:30AM +0100, Ciaran McCreesh wrote:
 On Wed, 5 Oct 2005 18:00:12 -0500 Brian Harring [EMAIL PROTECTED]
 wrote:
 | Beyond that, there is the shebang issue which can be addresses via a 
 | combination of automated scans/fixes, and fixing bugs as it's hit.  
 | Hardcoded vars in scripts for the path to a binary are an issue also, 
 | although again, scans can be done to at least check for it.
 
 This one's a far bigger issue than might be initially obvious. It would
 involve rewriting a whole load of autotools innards...
Clarify.  My knowledge of autotool innards is that it relies on $PATH 
for lookup of the tools it uses.

 | Leaves mangling the build process so that the build framework of the 
 | package uses the prefix offset files, rather then / .  For c/c++ 
 | source, usual trick from fink afaik involves a mangling of cflags
 | with -I tacked in.  Kinda ugly, although I'd expect there is a better 
 | route.
 
 Again, autoconf tinkering.
Statement above is from digging through generated configure script.
~harring


pgp3yrxiLkcfh.pgp
Description: PGP signature

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

[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 [EMAIL PROTECTED]
wrote:
| A) would like to hear what you think is required planning wise 
| compared to the previous haubi prototype patch.


There has been no serious discussion on how *ebuilds* will use the
prefix system. Hacking econf and expecting PREFIX to be sufficient is
naive from a tree-perspective.
   



econf isn't the only change required; the point is that whatever is 
decided, would have to be added to econf thus covering a good chunk of 
ebuilds in the tree that don't require fancy voodoo.


The basic proposal of haubi's glep (ignoring the portage innard 
modifications) came down to addition of a prefix var, that would be 
required slipped in for any fs installation paths (--prefix=$PREFX 
fex).


Beyond that, there is the shebang issue which can be addresses via a 
combination of automated scans/fixes, and fixing bugs as it's hit.  
Hardcoded vars in scripts for the path to a binary are an issue also, 
although again, scans can be done to at least check for it.


Leaves mangling the build process so that the build framework of the 
package uses the prefix offset files, rather then / .  For c/c++ 
source, usual trick from fink afaik involves a mangling of cflags with 
-I tacked in.  Kinda ugly, although I'd expect there is a better 
route.


Packages that pull include/compile settings/args from a utility 
(thinking python configuration tools, and pkgconfig) shouldn't be too 
horrid to change, since it's a matter of modifying it in one place 
(theoretically :).

~harring


 

I guess in the end trying to do something like this is a difficult 
process.  I am wary of anyone who wants to just jump into an application 
like portage and just magically write in this kind of support.  In the 
end one could just try and go step by step, but nothing guarantee's you 
won't miss something, or because it works with packages x,y,z that it 
will work for all packages.


If you have two weeks to do it in, I wish you the best of luck.  Maybe 
you are good enough at learning portage internals to get it done, but 
even after portage support is done there are still plenty of other factors.


In the end I side with Ciaran on this one.  You need to know all the 
bases to cover here in order to make this work well.  Going ahead with 
no plan is stupid IMHO.

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

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

[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 [EMAIL PROTECTED] wrote:
 Brian Harring wrote:

 On Wed, Oct 05, 2005 at 11:31:32PM +0100, Ciaran McCreesh wrote:
 
 
 On Wed, 5 Oct 2005 16:13:06 -0500 Brian Harring [EMAIL PROTECTED]
 wrote:
 | A) would like to hear what you think is required planning wise
 | compared to the previous haubi prototype patch.
 
 There has been no serious discussion on how *ebuilds* will use the
 prefix system. Hacking econf and expecting PREFIX to be sufficient is
 naive from a tree-perspective.
 
 
 
 econf isn't the only change required; the point is that whatever is
 decided, would have to be added to econf thus covering a good chunk of
 ebuilds in the tree that don't require fancy voodoo.
 
 The basic proposal of haubi's glep (ignoring the portage innard
 modifications) came down to addition of a prefix var, that would be
 required slipped in for any fs installation paths (--prefix=$PREFX
 fex).
 
 Beyond that, there is the shebang issue which can be addresses via a
 combination of automated scans/fixes, and fixing bugs as it's hit.
 Hardcoded vars in scripts for the path to a binary are an issue also,
 although again, scans can be done to at least check for it.
 
 Leaves mangling the build process so that the build framework of the
 package uses the prefix offset files, rather then / .  For c/c++
 source, usual trick from fink afaik involves a mangling of cflags with
 -I tacked in.  Kinda ugly, although I'd expect there is a better
 route.
 
 Packages that pull include/compile settings/args from a utility
 (thinking python configuration tools, and pkgconfig) shouldn't be too
 horrid to change, since it's a matter of modifying it in one place
 (theoretically :).
 ~harring
 
 
 
 
 I guess in the end trying to do something like this is a difficult
 process.  I am wary of anyone who wants to just jump into an application
 like portage and just magically write in this kind of support.  In the
 end one could just try and go step by step, but nothing guarantee's you
 won't miss something, or because it works with packages x,y,z that it
 will work for all packages.

 If you have two weeks to do it in, I wish you the best of luck.  Maybe
 you are good enough at learning portage internals to get it done, but
 even after portage support is done there are still plenty of other factors.

 In the end I side with Ciaran on this one.  You need to know all the
 bases to cover here in order to make this work well.  Going ahead with
 no plan is stupid IMHO.
 --
 gentoo-portage-dev@gentoo.org mailing list



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

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

[Brian Harring]

On Thu, Oct 06, 2005 at 12:38:35AM +0100, Ciaran McCreesh wrote:
 On Wed, 5 Oct 2005 18:22:37 -0500 Brian Harring [EMAIL PROTECTED]
 wrote:
 | On Thu, Oct 06, 2005 at 12:14:30AM +0100, Ciaran McCreesh wrote:
 |  On Wed, 5 Oct 2005 18:00:12 -0500 Brian Harring
 |  [EMAIL PROTECTED]
 |  wrote:
 |  | Beyond that, there is the shebang issue which can be addresses
 |  | via a combination of automated scans/fixes, and fixing bugs as
 |  | it's hit. Hardcoded vars in scripts for the path to a binary are
 |  | an issue also, although again, scans can be done to at least
 |  | check for it.
 |  
 |  This one's a far bigger issue than might be initially obvious. It
 |  would involve rewriting a whole load of autotools innards...
 |
 | Clarify.  My knowledge of autotool innards is that it relies on $PATH 
 | for lookup of the tools it uses.
 
 It does in some places, it doesn't in others. It especially doesn't for
 things that aren't normally found via PATH. It's a hell of a mess.
Examples?
~harring


pgpqc9GgtRZ5U.pgp
Description: PGP signature

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

[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 [EMAIL PROTECTED] wrote:
 


Brian Harring wrote:

   


On Wed, Oct 05, 2005 at 11:31:32PM +0100, Ciaran McCreesh wrote:


 


On Wed, 5 Oct 2005 16:13:06 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| A) would like to hear what you think is required planning wise
| compared to the previous haubi prototype patch.

There has been no serious discussion on how *ebuilds* will use the
prefix system. Hacking econf and expecting PREFIX to be sufficient is
naive from a tree-perspective.


   


econf isn't the only change required; the point is that whatever is
decided, would have to be added to econf thus covering a good chunk of
ebuilds in the tree that don't require fancy voodoo.

The basic proposal of haubi's glep (ignoring the portage innard
modifications) came down to addition of a prefix var, that would be
required slipped in for any fs installation paths (--prefix=$PREFX
fex).

Beyond that, there is the shebang issue which can be addresses via a
combination of automated scans/fixes, and fixing bugs as it's hit.
Hardcoded vars in scripts for the path to a binary are an issue also,
although again, scans can be done to at least check for it.

Leaves mangling the build process so that the build framework of the
package uses the prefix offset files, rather then / .  For c/c++
source, usual trick from fink afaik involves a mangling of cflags with
-I tacked in.  Kinda ugly, although I'd expect there is a better
route.

Packages that pull include/compile settings/args from a utility
(thinking python configuration tools, and pkgconfig) shouldn't be too
horrid to change, since it's a matter of modifying it in one place
(theoretically :).
~harring




 


I guess in the end trying to do something like this is a difficult
process.  I am wary of anyone who wants to just jump into an application
like portage and just magically write in this kind of support.  In the
end one could just try and go step by step, but nothing guarantee's you
won't miss something, or because it works with packages x,y,z that it
will work for all packages.

If you have two weeks to do it in, I wish you the best of luck.  Maybe
you are good enough at learning portage internals to get it done, but
even after portage support is done there are still plenty of other factors.

In the end I side with Ciaran on this one.  You need to know all the
bases to cover here in order to make this work well.  Going ahead with
no plan is stupid IMHO.
--
gentoo-portage-dev@gentoo.org mailing list


   



My point was not to scare you so much as to make you aware of the 
problems you will face.  Most of them are not portage problems.  Most of 
the problems are ebuild problems, found in each piece of software that 
will be used in this manner.  All of the ebuilds are written for one 
domain, and now they are being used in another.  Ciaran has already 
given a few examples of the trouble.  In this case Getting it to work 
is easy.  Getting it to work for all packages = a ton of work.


-Alec
PS: Nothing I say should stop you, I am by no means an expert.
PSS: Good Luck.
--
gentoo-portage-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

On Wed, 5 Oct 2005 18:40:46 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
|  It does in some places, it doesn't in others. It especially doesn't
|  for things that aren't normally found via PATH. It's a hell of a
|  mess.
|
| Examples?

Of stuff in PATH? /bin/sh is assumed throughout to be a Bourne
compatible shell (and SHELL and CONFIG_SHELL aren't universally
honoured). uname, hostname and sed are called with hard paths (with
various fallbacks) in several early on stages. Of stuff not in path?
There's no standard and widely used way of digging up where libexec
tools are.

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



pgpaizwnjub0S.pgp
Description: PGP signature

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

[Brian Harring]

On Thu, Oct 06, 2005 at 01:13:53AM +0100, Ciaran McCreesh wrote:
 On Wed, 5 Oct 2005 18:40:46 -0500 Brian Harring [EMAIL PROTECTED]
 wrote:
 |  It does in some places, it doesn't in others. It especially doesn't
 |  for things that aren't normally found via PATH. It's a hell of a
 |  mess.
 |
 | Examples?
 
 Of stuff in PATH? /bin/sh is assumed throughout to be a Bourne
 compatible shell (and SHELL and CONFIG_SHELL aren't universally
 honoured). uname, hostname and sed are called with hard paths (with
 various fallbacks) in several early on stages. Of stuff not in path?
 There's no standard and widely used way of digging up where libexec
 tools are.
What's being raised here is issues with making ebuilds handle prefix 
_perfectly_.  Where are the portage issues, so that people can 
actually jump in and start testing out actual solutions, rather then 
conjecturing about what may or may not break?
~harring


pgpvDKijE0RXh.pgp
Description: PGP signature

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

[Ciaran McCreesh]

On Wed, 5 Oct 2005 20:01:34 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| What's being raised here is issues with making ebuilds handle prefix 
| _perfectly_.  Where are the portage issues, so that people can 
| actually jump in and start testing out actual solutions, rather then 
| conjecturing about what may or may not break?

The issue is that you need to fix autoconf before you can claim that
any non-trivial test case works correctly.

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



pgpuwdeoxEWcC.pgp
Description: PGP signature

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

[Ciaran McCreesh]

On Wed, 5 Oct 2005 20:17:40 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
|  The issue is that you need to fix autoconf before you can claim that
|  any non-trivial test case works correctly.
| 
| And how are you going to verify autoconf works perfectly without 
| testing it?

Can't. Dead easy to verify that it will break without testing it,
though. Just look at the source.

| The point I'm making is that the only thing required of *portage*, is 
| the prefix var being used internally, and handed down to the ebuilds.
| 
| Ironing out the ebuild cruft is left to those who want it.  Again, 
| where is the hold up for *portage*?

That's rather short-sighted... Portage is irrelevant without the
ebuilds.

| What's the problem?  Why the 101 holes before they even can attempt 
| it?  If you're after shooting the idea down (as I suspect), state so 
| rather then death by a thousand cuts.  Saves us time, really.
| 
| Hell, haubi's patch already lays the ground work for testing it.  I'm 
| not seeing why you're being negative about people even working on it.

Because a botched solution is worse than no solution at all. You've
seen the mess we end up with when people start working with a
half-arsed initial setup.

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



pgpEgTt9aTo0S.pgp
Description: PGP signature

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

[Brian Harring]

On Thu, Oct 06, 2005 at 02:23:47AM +0100, Ciaran McCreesh wrote:
 On Wed, 5 Oct 2005 20:17:40 -0500 Brian Harring [EMAIL PROTECTED]
 wrote:
 |  The issue is that you need to fix autoconf before you can claim that
 |  any non-trivial test case works correctly.
 | 
 | And how are you going to verify autoconf works perfectly without 
 | testing it?
 
 Can't. Dead easy to verify that it will break without testing it,
 though. Just look at the source.
Break is a bit heavy, considering autoconf's usage of /bin/sh is 
pretty limited in terms of syntax.  Looking at the source, it'll 
revert to / for certain bins.  

A forced autoreconf with a patched autoconf/autotools 
is required, but again, doesn't do jack with out testing.

 | The point I'm making is that the only thing required of *portage*, is 
 | the prefix var being used internally, and handed down to the ebuilds.
 | 
 | Ironing out the ebuild cruft is left to those who want it.  Again, 
 | where is the hold up for *portage*?
 
 That's rather short-sighted... Portage is irrelevant without the
 ebuilds.

And ebuilds are irrelevant without portage.  Point?
My point experimentation can start for addressing the issues you keep 
pointing at still stands.

 
 | What's the problem?  Why the 101 holes before they even can attempt 
 | it?  If you're after shooting the idea down (as I suspect), state so 
 | rather then death by a thousand cuts.  Saves us time, really.
 | 
 | Hell, haubi's patch already lays the ground work for testing it.  I'm 
 | not seeing why you're being negative about people even working on it.
 
 Because a botched solution is worse than no solution at all. You've
 seen the mess we end up with when people start working with a
 half-arsed initial setup.

Well plan the sucker out then, as you advocated, or sit back and let 
them jump in and start working it out.

Perhaps they'll decide it's completely unworkable (I doubt it, 
considering the fact fink's crappy handling of building has made it 
this far), or perhaps they'll get it working and you won't have as 
many holes to point at.

Regardless, it's their time to spend working on it.  Either chip in, 
or offer _constructive_ advice, or plain step back and let them try to 
get it working.

Note the constructive.  Stating it won't work and pulling a new reason 
why isn't constructive, pointing out each issue as you see it so they 
can address it (if it's an issue) is a bit more constructive.
~harring


pgpLpvBGoQzGq.pgp
Description: PGP signature

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

[Ciaran McCreesh]

On Wed, 5 Oct 2005 20:32:20 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
|  That's rather short-sighted... Portage is irrelevant without the
|  ebuilds.
| 
| And ebuilds are irrelevant without portage.  Point?

Portage is considerably less work than the tree. Saving as much effort
as possible from an ebuild perspective should be a major consideration,
even if it makes the portage side more complicated. Think of how all
the ebuild-related problems are going to be solved first. Don't leave
it as an afterthought.

| My point experimentation can start for addressing the issues you keep 
| pointing at still stands.

The sensible place to start experimenting is by adapting existing
ebuilds and tinkering with ebuild.sh, not by adding something which may
or may not end up being relevant to portage proper.

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



pgpnbNAjoxpwk.pgp
Description: PGP signature

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

[Brian Harring]

On Thu, Oct 06, 2005 at 02:40:58AM +0100, Ciaran McCreesh wrote:
 On Wed, 5 Oct 2005 20:32:20 -0500 Brian Harring [EMAIL PROTECTED]
 
 Portage is considerably less work than the tree. Saving as much effort
 as possible from an ebuild perspective should be a major consideration,
 even if it makes the portage side more complicated. Think of how all
 the ebuild-related problems are going to be solved first. Don't leave
 it as an afterthought.
Round and round we go.

The ebuild related problems aren't going to be solved in portage till 
someone has a general solution that can be pushed into 
portage/ebuild.sh base template.  That's something that requires 
people diving in and screwing with it.

 | My point experimentation can start for addressing the issues you keep 
 | pointing at still stands.
 
 The sensible place to start experimenting is by adapting existing
 ebuilds and tinkering with ebuild.sh, not by adding something which may
 or may not end up being relevant to portage proper.

Bluntly, what the hell do you think we're talking about here?  In case 
you haven't caught on, there *are* portage modifications that have to 
go with it, meaning more then ebuild.sh.

Regardless, I'll backport haubi's patch to stable if anyone is after 
screwing with it, unless michael's has a version that applies cleanly 
to .53_rc4.  Enough dancing, would rather hand it off to those who are 
interested, and see what they come up with rather then fencing via 
email (and accomplishing nothing).

Michael, got anything I can mold to .5*, or just backport the 2.1 mod?
~harring


pgpmLvkkFehel.pgp
Description: PGP signature

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

[Kito]

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


On Wed, 5 Oct 2005 18:40:46 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
|  It does in some places, it doesn't in others. It especially  
doesn't

|  for things that aren't normally found via PATH. It's a hell of a
|  mess.
|
| Examples?

Of stuff in PATH? /bin/sh is assumed throughout to be a Bourne
compatible shell (and SHELL and CONFIG_SHELL aren't universally
honoured). uname, hostname and sed are called with hard paths (with
various fallbacks) in several early on stages. Of stuff not in path?
There's no standard and widely used way of digging up where libexec
tools are.


	Its not like this is unchartered territory... off the top o' me head  
pkgsrc, DarwinPorts, openpkg, fink, written word, autopackage, MINE,  
and SamHain have all tackled this in one way or the other. All of  
these projects have their faults (duh? but then again so does portage  
and the ebuild tree) but a few of them have been quite successful  
despite their varying points of inherent silliness.


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

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

[Ciaran McCreesh]

On Wed, 5 Oct 2005 20:48:26 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
|  The sensible place to start experimenting is by adapting existing
|  ebuilds and tinkering with ebuild.sh, not by adding something which
|  may or may not end up being relevant to portage proper.
| 
| Bluntly, what the hell do you think we're talking about here?  In
| case you haven't caught on, there *are* portage modifications that
| have to go with it, meaning more then ebuild.sh.

And you don't have a clue what said modifications really are until
after you solve the ebuild side of things. The correct way to solve the
problem is as follows:

1. Properly define what you are trying to solve from an end result
perspective.
2. Properly define and provide substantial examples of how this can be
done sanely through ebuilds.
3. Work out how this applies to portage.
4. Make sensible small revisions to 2. and 1. as necessary based upon
any problems encountered in 3.

The wrong way is as follows:

1. Jump in with some portage code which does something random.
2. Come up with a badly thought out incomplete requirements list.
3. Start hacking ebuilds into an even worse mess to accommodate earlier
screwups.

And for the sake of completeness, the other wrong way which isn't being
taken this time is:

1. Come up with some buzzwords.
2. ???
3. Profit!

| Regardless, I'll backport haubi's patch to stable if anyone is after 
| screwing with it, unless michael's has a version that applies cleanly 
| to .53_rc4.  Enough dancing, would rather hand it off to those who
| are interested, and see what they come up with rather then fencing
| via email (and accomplishing nothing).

*sniff* *sniff* Ah yes, the familiar smell of multilib, osx, genkernel
and the original portage implementation.

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



pgpSjJb9MkVhc.pgp
Description: PGP signature

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

[Ciaran McCreesh]

On Wed, 5 Oct 2005 20:56:42 -0500 Kito [EMAIL PROTECTED] wrote:
|   Its not like this is unchartered territory... off the top o'
| me head pkgsrc, DarwinPorts, openpkg, fink, written word,
| autopackage, MINE, and SamHain have all tackled this in one way or
| the other. All of these projects have their faults (duh? but then
| again so does portage and the ebuild tree) but a few of them have
| been quite successful despite their varying points of inherent
| silliness.

Sure. They work around it by having lots and lots of workaround code,
not by solving the original problem.

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



pgpbIJpgq1dzl.pgp
Description: PGP signature

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

[Kito]

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


On Wed, 5 Oct 2005 20:56:42 -0500 Kito [EMAIL PROTECTED] wrote:
|   Its not like this is unchartered territory... off the top o'
| me head pkgsrc, DarwinPorts, openpkg, fink, written word,
| autopackage, MINE, and SamHain have all tackled this in one way or
| the other. All of these projects have their faults (duh? but then
| again so does portage and the ebuild tree) but a few of them have
| been quite successful despite their varying points of inherent
| silliness.

Sure. They work around it by having lots and lots of workaround code,
not by solving the original problem.


Most of the workaround code I see in the few of these I'm acquainted  
with is in the various bootstrap mechanisms, and the general  
deficiency of the underlying PM, i.e. no sane package versioning  
scheme (ports like python24, gcc3,gcc4, etc.), no globally defined  
'build opts'(read: use flags), and nowhere to store platform specific  
knowledge (profiles), so all that crap ends up being stuffed directly  
in their portfiles.




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



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

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

[Brian Harring]

On Thu, Oct 06, 2005 at 03:01:12AM +0100, Ciaran McCreesh wrote:
 On Wed, 5 Oct 2005 20:48:26 -0500 Brian Harring [EMAIL PROTECTED]
 wrote:
 |  The sensible place to start experimenting is by adapting existing
 |  ebuilds and tinkering with ebuild.sh, not by adding something which
 |  may or may not end up being relevant to portage proper.
 | 
 | Bluntly, what the hell do you think we're talking about here?  In
 | case you haven't caught on, there *are* portage modifications that
 | have to go with it, meaning more then ebuild.sh.
 
snip lots of you're doing something I think is dumb/I don't 
agree/slams at pvdabeel/lv/others who have attempted things in the tree

Clarification of two things.

First- this is external, including the patch.  So comparing it to 
attempts that were done in a live tree is a bit of 
intentional bullshit/rhetoric.  

The entire intention of this is to work it out, *outside* of the tree, 
something those involved know.  You seem to be out of the loop, not 
surprising considering your attitude towards this whole attempt.

Second- Not having a clue about what the full set of modifications are 
going to be until you solve the ebuild side of it is *exactly* why 
people have to jump in and actually test the damn thing.  You can solve 
as much of it up front as you know will be an issue, testing will reveal the 
additional issues.  Under your suggested route, nothing is 
accomplished (potentially the reason you're suggesting all issues up 
front be addressed regardless of whether or not if they'll actually 
_be_ issues).

What you're offering as a proposed/sane route is a route that produces 
nothing due to the fact you think everything must be solved up front, 
regardless if it turns out to be an issue or not (let alone 
identifying everything that may or may not be an issue) .  Get the 
basic portage support up, they iron out the base mods initially needed, 
and jump in and identify the bugs that crop up further.

Essentially, lets see how well this actually works out, rather then 
listening to you run your mouth about how it's a bad idea whenever it 
comes up, and all of these things will be issues (/bin/sh usage isn't 
an issue for the initial test target of osx).

Either way, they're doing the work, you aren't, and you really don't 
have *any* say over their efforts until they finalize a solution 
and bring it to *devs* (not just you) for merging into mainline.

So bluntly, shut up and let those who you think are being retarded, 
be retarded.  Discussions on this list regarding those attempts 
shouldn't be heckled unless you're contributing to those efforts (and 
I truly mean *contributing*, not trying to punch holes in embryonic 
efforts that are trying to get off the ground addressing the major 
issues up front).

Regardless, your points (repeatedly restated in the varying forms) 
have been noted, and those who are interested have no reason to not 
move forward with ironing out an implementation, and testing it.

I suggest you sit quietly and let them do their work, rather then 
riding their asses.

You might be surprised at what they come up with. 

If/When they push for inclusion, the merits of their efforts their 
solution (and outstanding issues) will be evaluated then.  Back 
off and let them do their work, it's not affecting you in anyway, so 
again, you really don't have any say in it till they push for 
mainline.

So... yeah.  I'll post the prefix support backport patch once it's 
done, few days I'd expect since there is a fair amount of autotooling 
to deal with also.

Those interested, I suggest you chip in, whether to spite ciaran 
(good or bad reasons, doesn't matter, result does :), or to get this 
feature you want realized.
~harring


pgpadtl900v4S.pgp
Description: PGP signature

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

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

On Thu, Oct 06, 2005 at 02:14:32PM +1000, Finn Thain wrote:
 
 
 On Wed, 5 Oct 2005, Kito wrote:
 
 [snip]
  
  My first question would be how to identify ebuilds that respect ${prefix}?
  
  A separate profile/keyword seems wrong.
  
  ICANINSTALLTO was the best idea presented, but that implies it would be 
  a list of known working prefixes, which seems unrealistic.
 
 What problem was ICANINSTALLTO intended to solve? IIRC, it was discussed 
 on -dev in the context of vim plug-ins. Apart from vim plugins, has anyone 
 found other problem packages?
 
 I'm wondering, would a constraint to the effect that certain deps of pkg 
 foo must be on the same prefix as foo suffice for the vim plugin case?
 
 Or maybe that would work better if expressed, pkg blah can not satisfy a 
 dep from any pkg on a different prefix. Such constraints would be 
 possible to implement with a new file in the profile (say, package.local).
That gets into more of ciaran's HOME installation target feature.
Current form for global prefix offset is
DOMAIN=root offset , with offset == prefix offset.

If an ebuild doesn't have DOMAIN=offset, and you're doing a prefix 
offset, it's unusable.  No question of can I use a dep from another 
prefix, with prefix offset you're doing the deps full in an offset.

As stated earlier in this mess of a thread, HOME crap is being left to 
those who want it, it'll be implemented by those who want it after 
global prefix is ironed out (if it is accepted also).
~harring


pgpEHAG0zrtZw.pgp
Description: PGP signature