From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.polybottom.org (polybottom.org [66.220.1.110]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j46D8ULl012996 for ; Fri, 6 May 2005 13:08:30 GMT Received: from [10.10.10.56] ([::ffff:12.45.184.236]) (AUTH: LOGIN brian@brianandsara.net) by mail.polybottom.org with esmtp; Fri, 06 May 2005 08:08:35 -0500 id 000097FB.427B6C53.00003F57 Message-ID: <427B6D27.8000506@gentoo.org> Date: Fri, 06 May 2005 08:12:07 -0500 From: Brian Jackson User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050425) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] new glep draft: Portage as a secondary package manager References: <42761B77.4030206@salomon.at> <20050502151356.6d9ca385@snowdrop> <20050503000229.GA10998@exodus.wit.org> <20050503151220.076cc62f@snowdrop> <20050505084849.GC13705@exodus.wit.org> <20050505150105.7fc5f5de@snowdrop> <20050506050958.GH13705@exodus.wit.org> In-Reply-To: <20050506050958.GH13705@exodus.wit.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: c5e71ded-e07f-45b1-934c-f91c68f1dda9 X-Archives-Hash: 36deabb62dbcc3721df47fef7c289b59 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 >>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