Re: [gentoo-dev] new glep draft: Portage as a secondary package manager

[Brian Harring <ferringb@gentoo.org>]

On Thu, May 05, 2005 at 03:01:05PM +0100, Ciaran McCreesh wrote:
> On Thu, 5 May 2005 03:48:49 -0500 Brian Harring <ferringb@gentoo.org>
> wrote:
> | > Ok, here's the main issue. Simply changing prefix isn't enough to
> | > automatically make every package in the tree work. A heck of a lot
> | > of them will need manual modification, and there's no easy way to
> | > figure out which these are. So...
> | 
> | Err.  ROOT!="/" exists already, and directly screws with prefixes.  So
> | this doesn't seem particularly valid in light of that fact.
> 
> No, root doesn't screw with prefixes.

"Which brings me to my next point, kids don't do crack."
I'm pleading temporary insanity on that one.

That said, I'll just point at fink's nonstandard prefix for 
installation as a better example that it *can* be pulled off without 
all of this 'fire, brimstome, and the apocalypse on earth' cruft 
people keep throwing about as an arguement it can't work.

Think about it for a second.  What is the purpose of --prefix, and all 
the other lovely configure installation options?  To configure the 
source so it'll work in it's intended destination.

Yes, it doesn't work perfectly across all packages, and not all 
packages are designed to be flexible in installation (straight 
makefile hacks come to mind, dev-util/bsdiff for example).  This is 
why I keep pointing at the parallel of adding a new arch.  You get 
your core support down, and expand support across the tree as you go.

In other words, yes, there are technical issues, but I _still_ posit 
that those issues are experienced by those who want said support, and 
who are the lucky buggers who have to do the bug squashing.  It's the 
same damn thing macos encounters, and any new arch, hence my complete 
lack of understanding for why people are quick to fire off "piss off, 
it won't work" without looking at the actual issues.


> | > Thing is, if we introduce the PREFIX feature, people will expect it
> | > to actually work. It won't, at least not straight away, because
> | > there are so many ebuilds that use more than econf to get the prefix
> | > figured out. By whitelisting we can at least display a nice "you
> | > can't install this package in a prefix" message.
> | 
> | Not a valid arguement to exempt even trying.
> | 
> | Consider if people used that arg for avoiding porting linux to new 
> | arches-  Linux would still be strictly x86.
> 
> Eh? No, see, we have KEYWORDS, which indicate whether you can use a
> package on a given arch.

Dodging my point.  You stated, "if we introduce it, people will expect 
it to actually work".  It's defeatist logic; won't try because people 
might bitch if they wade into experimental territory and get bit.

That's the point I was getting at, which you seemed to ignore/not 
understand.

Pointing out that people might try an experimental feature and hit 
issues and bitch as a reason for _not_ doing something is just plain 
daft.

The porting of linux to a new arch is a valid analogy there; for the 
person to even try it, they have to venture off the beaten path, past 
many warnings about it being experimental.  If they shoot themselves 
in the foot/hit issues, well, they're big boys/girls and they can fend 
for themselves.

They are, after all, the ones who ventured off the beaten path and 
started screwing with an experimental feature.  It's their 
responsibility, and arguing that we shouldn't attempt something 
because people might bitch is a weak arguement, basically an attempt 
to shoot down the proposal without a valid reason.


> | > Yet another issue... As it stands, all deps must be installed into
> | > the given PREFIX. This is messy. Is there a way around this?  This
> | > would be less of a problem with ICANINSTALLTO="home" -- presumably
> | > for these portage could pass a var to the ebuild telling it in which
> | > prefix to look for its deps.
> | 
> | injections, mainly.
> 
> Nasty hack.

Alternative being what, auto detection of files on disk to map it back 
to ebuild nodes?  I'd posit that's equally nasty.

Call it a hack if so desired, but that's the purpose of 
injections/provided, and is the basis of the osx port from a dep 
resolution standpoint.

If you've got a better suggestion, macos probably would love to know 
of it ;)

So, fink demonstration of --prefix hackery?
~brian
-- 
gentoo-dev@gentoo.org mailing list