Brian Harring wrote: >On Thu, May 05, 2005 at 03:01:05PM +0100, Ciaran McCreesh wrote: > > >>On Thu, 5 May 2005 03:48:49 -0500 Brian Harring <[EMAIL PROTECTED]> >>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. > >
Okay, I'll stop shooting. But I suggest that this is a particular GLEP where a reference implementation (outside of the main portage tree) would aid people in studying the GLEP. The GLEP workflow section allows for this. I'd say at least a standard emerge system should be working before this GLEP is approved. --Iggy > > > >>| > 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
