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