On Tue, May 03, 2005 at 03:12:20PM +0100, Ciaran McCreesh wrote: > On Mon, 2 May 2005 19:02:29 -0500 Brian Harring <[EMAIL PROTECTED]> > wrote: > | State said problem for the general community. Guessing you're > | referencing the issue/request that being able to manage home, and > | 'global' installations? > | > | I'd still posit that the issue of installing to a user's home when > | portage's base prefix is /usr/local (fex) is a seperate issue. What > | you were requesting for vim plugins goes beyond haubi's initial > | goals... > > 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. > My suggested way around this was to have a variable in ebuilds. Call it > something like ICANINSTALLTO (that name sucks, come up with something > better), which defaults to ICANINSTALLTO="usr". Ebuilds which have been > explicitly checked and designed by the maintainer for prefix installs > get ICANINSTALLTO="usr prefix". I'd be curious about the _actual_ number of packages that lose their asses when the base prefix is not /usr in light of root tomfoolery mentioned above. Note, I'm not talking about installing plugins to a seperate prefix within a managed domain (portage as the primary pkg manager, '/' is it's domain effectively). > This also allows us to do other cool stuff like ICANINSTALLTO="home", > for things like vim and gkrellm plugins which can go in ~/.vim/ and > ~/.gkrellm2/plugins/ respectively. Regarding specifying 'targets', yes, with limits, although I don't think it's a valid arguement (currently) against haubi's proposal. Reasoning is thus, root already directly screws with the prefix for a good collection of packages. What you're after above is a way to specify multiple prefixes for a single portage installation Falling back to portage as the primary pkg manager, you basically seem to be after emerge --target home vim-plugin vs emerge --target default vim-plugin default being use or use/local or whatever the hell So... short version, ICANINSTALLTO is down the line. Baby steps. What you're after above requires haubi's modifications, and _more_. Peg off the issues one by one to get to ICANINSTALLTO="home", instead of trying to pull it all off in a single magic bullet. > 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. > Another issue... Portage installs to /usr/local are no good, because > there might be other non-portage installs there too. If we're installing > to a prefix, we have to be the *only* thing installing there. No other > packages, not even other manual installs. Collision-protect anyone? :) Seriously though, if they're using portage as a secondary manager and using other pkg managers that install to /usr/local, it's the admin's responsibility to handle it. The proposal isn't requesting we go querying through rpm's db to make sure we're not stomping anything, it's goal is to extend portage (and ebuild conventions) so that _using_ it as a secondary manager w/out installing to / is viable. So... easy hole in that arguement is having each secondary manager use it's own base prefix. > 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. Your ICANINSTALLTO bit, when operating within the same installation (see emerge --target bit above) would require multiple vdb's, and portage being smart enough to handle N vdbs. Portage is still stuck in the special classes. As mentioned above, changes to ebuild conventions and changes to portage repository handling is required. Baby steps... > That'll do for now. I'll shoot some more holes in it once these have > been figured out. Fire away, looking forward to the next attempt ;) ~brian -- gentoo-dev@gentoo.org mailing list
