[gentoo-dev] prefix overide portage

[gentoo-dev] prefix overide portage

[Matt Doughty]

Hi,
I hate to start by complaining or critisizing what I consider a
wonderful project.  I'm basically a NetBSD user who is looking
for functionality(hardware 3d support) that linux has, and 
NetBSD is lacking. I was working through the install, and ran
into a couple oddities/annoyances.  I noticed that alot of
packages in portage statically set the install prefix.  I find
this to be very undesirable behavior, and was wondering if
this is temporary or has noone complained about this rather
rigid structure? From my perspective a system should be divided 
in this manner:

base system (kernel, and userland): 	--prefix=/, and --prefix=/usr
package system installed pkgs:     	--prefix=/usr/pkg
X system:			 	--prefix=/usr/X11R6

this leaves /usr/local, and /opt for hand built packages. In NetBSD
the base system is completely seperate from the package system, and
the package system, and X prefixes can be overridden by the 
enviroment variables LOCALBASE, and X11BASE respectively. I love 
the overall design of the system, and clean nature of the /etc
directory.  I would be happy to help make the needed changes to
allow for this increased flexibility.

--Matt

Re: [gentoo-dev] prefix overide portage

[Bruce A. Locke]

On Tue, 2002-02-19 at 09:13, Matt Doughty wrote:
> Hi,
> I hate to start by complaining or critisizing what I consider a
> wonderful project.  I'm basically a NetBSD user who is looking
> for functionality(hardware 3d support) that linux has, and 
> NetBSD is lacking. I was working through the install, and ran
> into a couple oddities/annoyances.  I noticed that alot of
> packages in portage statically set the install prefix.

Yes alot of packages are setup that way.  I'm of a mixed opinion if
thats a good or a bad thing.  If we do decide to make it more
configurable down the road its going to require alot of ebuild touchups,
etc.  Alot of configure scripts require path information to headers,
assume files are in various locations, etc.  I can tell from experience
if you set a less-then-common prefix many configure scripts are going to
break on you (meaning we'd have to hack on a bunch of them :(

> I find this to be very undesirable behavior, and was wondering if
> this is temporary or has noone complained about this rather
> rigid structure? 

Don't think many people have complained of it yet :)

> From my perspective a system should be divided 
> in this manner:
> 
> base system (kernel, and userland): 	--prefix=/, and --prefix=/usr
> package system installed pkgs:     	--prefix=/usr/pkg
>
> X system:			 	--prefix=/usr/X11R6
> this leaves /usr/local, and /opt for hand built packages. In NetBSD
> the base system is completely seperate from the package system, and
> the package system, and X prefixes can be overridden by the 
> enviroment variables LOCALBASE, and X11BASE respectively. I love 
> the overall design of the system, and clean nature of the /etc
> directory.  I would be happy to help make the needed changes to
> allow for this increased flexibility.

Gentoo makes no distinction between its "core" and packages.  Every part
of the core (kernel, glibc, etc) is treated _exactly_ the same as any
other package.  Portage handles compiling and package manangement
(except for the kernel, you still have to compile that yourself ;)  We
used to split gnome, kde, etc up into /opt/kde, etc but it later became
a mess.

/usr/X11R6 on gentoo is currently only really used by XFree86
packages... All X programs go under /usr not /usr/X11R6.  (We also have
/usr/kde/2 and /usr/kde/3 for kde so users can have the stable kde2
installed while playing with kde 3-cvs).

The only package I'm aware of that touches /usr/local is apache, and
that ebuild is in the process of being rewritten.

/opt is used for those packages which can't be easily made to fit within
a FHS compliant file system.  For instance java packages are not
designed to be installed in /usr/bin, etc without alot of hassle...

 
> --Matt
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
> 
-- 

Bruce A. Locke
blocke@shivan.org

Re: [gentoo-dev] prefix overide portage

[Dave Lee]

Bruce A. Locke wrote:
> On Tue, 2002-02-19 at 09:13, Matt Doughty wrote:
> > Hi,
> > I hate to start by complaining or critisizing what I consider a
> > wonderful project.  I'm basically a NetBSD user who is looking
> > for functionality(hardware 3d support) that linux has, and 
> > NetBSD is lacking. I was working through the install, and ran
> > into a couple oddities/annoyances.  I noticed that alot of
> > packages in portage statically set the install prefix.
> 
> Yes alot of packages are setup that way.  I'm of a mixed opinion if
> thats a good or a bad thing.  If we do decide to make it more
> configurable down the road its going to require alot of ebuild touchups,
> etc.  Alot of configure scripts require path information to headers,
> assume files are in various locations, etc.  I can tell from experience
> if you set a less-then-common prefix many configure scripts are going to
> break on you (meaning we'd have to hack on a bunch of them :(

I don't think this would actually be "hacking", I would call it something
much nicer, like cleaning up.  I can see the desire to set a custom
install prefix, and I think that making the ebuild scripts more flexible
to allow for this may prove useful in that it will make the portage system
much more flexible and customizable.  It should't be too much effort to
let loose some scripts on the portage tree to fix --preifx=/usr to
--preifx=$SOME_PREFIX_VAR where the SOME_PREFIX_VAR can be set in 
/etc/make.conf.  In another thread Vitaly Kushneriuk said "the Gentoo way 
is to provide user with the maximum control that is practical" and I dont
think having a custom prefix would be impractical.  Anyway, just my
thoughts on the subject.  One thing to note is that I noticed the ebuild
system is "rigid" like this in more ways than just preifx, every other
configure variable is hardcoded by the ebuild author into the ebuild file,
like mandir and others.  In rpm systems, when you create an rpm spec, you
can use %{_prefix} and %{_mandir} when you build rpms, and that gives it
some flexibility.

Dave

Re: [gentoo-dev] prefix overide portage

[Arcady Genkin]

Dave Lee <davel@canuck.com> writes:

>> > I noticed that alot of packages in portage statically set the
>> > install prefix.
>> 
>> Yes alot of packages are setup that way.  I'm of a mixed opinion if
>> thats a good or a bad thing.  If we do decide to make it more
>> configurable down the road its going to require alot of ebuild touchups,
>> etc.  Alot of configure scripts require path information to headers,
>> assume files are in various locations, etc.  I can tell from experience
>> if you set a less-then-common prefix many configure scripts are going to
>> break on you (meaning we'd have to hack on a bunch of them :(
>
> I don't think this would actually be "hacking", I would call it something
> much nicer, like cleaning up.  

I could not agree more.  I think that it would be extremely useful to
be able to set a custom prefix for packages installation.  There is a
large upgrade coming up in our lab, and I'm going to try to make a
case for Gentoo to replace Redhat.  But I know that one of the
problems that my boss is going to point out is inability to easilly
package software into /local (our conventional location) instead of
/usr.

> It should't be too much effort to let loose some scripts on the
> portage tree to fix --preifx=/usr to --preifx=$SOME_PREFIX_VAR where
> the SOME_PREFIX_VAR can be set in /etc/make.conf.

There's more to it than that, but, arguably, nothing that cannot be
done.

I, too, suggest that we introduce the functionality of the custom
package prefix in /etc/make.conf.
-- 
Arcady Genkin
Don't read everyting you believe.

Re: [gentoo-dev] prefix overide portage

[Matt Doughty]

<SNIP>
> 
> I, too, suggest that we introduce the functionality of the custom
> package prefix in /etc/make.conf.
> -- 
to me I see two logical configurable prefixes:
X11: I understand that is currently default to /usr/X11R6, and I
     consider this a good default, but there is no reason to set
     it in stone.
Portage packages: leaving the default to /usr is fine, but I would
     really think that shouldn't become a dumping ground like it has
     in so many other distros.  I can understand those who don't care
     can leave it in default dumping ground mode, and still allow
     those of us who like a "cleaner" solution to have our way.

I personally would like to leave /bin,/sbin,/lib /usr/bin,/usr/lib,
and /usr/sbin alone after the initial bootstrap. I don't want 
optional packages to intermingle in the same file space as those
that are needed for the system to function.  The ability to create
a clean delineation is doing the right thing(TM) from my perspective.

I think this really ammounts to good engineering, and if the goal is
to be more flexible than the ports/pkgsrc system this is needed
functionality.

On a related note, I think it would be wise to clearly delineate 
packages that are needed for basic booting system in some way. If
this functionality already exists, and I missed it please let me
know.  My main thought here is I want the ability to rebuild the
base system readily. Actually the more I think of it the better it
would be if one could say bootstrap a system to test directory first
(maybe /usr/local/base-test) and then assuming a possibly even chrooting
to test the new base simply reinstall the proper place or rerun the
bootstap without the overridden directory.  One way or another the 
ability to override the target for a package has many practical
applications.  Once again, let me know what I can do to help with this.

--Matt

Re: [gentoo-dev] prefix overide portage

[Bruce A. Locke]

On Wed, 2002-02-20 at 02:02, Matt Doughty wrote:
> Portage packages: leaving the default to /usr is fine, but I would
>      really think that shouldn't become a dumping ground like it has
>      in so many other distros.  I can understand those who don't care
>      can leave it in default dumping ground mode, and still allow
>      those of us who like a "cleaner" solution to have our way.

Yes its a matter of personal preference.  Personally I hated fbsd's use
of /usr/local and the filesystem looked quite cluttered and unorganized
(ditto goes for Solaris).  But it is a matter of personal preference.

> I personally would like to leave /bin,/sbin,/lib /usr/bin,/usr/lib,
> and /usr/sbin alone after the initial bootstrap. I don't want 
> optional packages to intermingle in the same file space as those
> that are needed for the system to function.  The ability to create
> a clean delineation is doing the right thing(TM) from my perspective.

Again a preference.  I don't share your view as there is no technical
basis for the view in my opinion.  There is no /usr/src in gentoo and no
seperation between "core" and "optional".  But there should be nothing
to stop you from doing what you want :)
 
> I think this really ammounts to good engineering, and if the goal is
> to be more flexible than the ports/pkgsrc system this is needed
> functionality.

Agreed.
 
> On a related note, I think it would be wise to clearly delineate 
> packages that are needed for basic booting system in some way. If
> this functionality already exists, and I missed it please let me
> know.

Gentoo supports the concept of profiles.   Much more powerful then a
simply marking something as "core", etc :)

See /usr/portage/profiles/default-1.0_rc6/packages and the portage
source code for more information.

>  My main thought here is I want the ability to rebuild the
> base system readily. Actually the more I think of it the better it
> would be if one could say bootstrap a system to test directory first
> (maybe /usr/local/base-test) and then assuming a possibly even chrooting
> to test the new base simply reinstall the proper place or rerun the
> bootstap without the overridden directory.

You can (kinda) do that already though its not as elegant as having a
relocatable prefix.  You could grab our build tarball from the website,
untar it into a directory, chroot it, and follow steps similar to those
outlined in the install guide.  If you want to play around with usermode
linux, just toss the tarball on a loopback filesystem and go from there
:)

> One way or another the 
> ability to override the target for a package has many practical
> applications.  Once again, let me know what I can do to help with this.

>From my understanding we'd need some variables defined in /etc/make.conf
or /etc/make.globals (with current behaviors as the default) and support
in portage to override these variables on a per package basis from the
comamnd line.  Does portage already have this functionality in
1.8.9-pre*?

After that it would be a matter of people interested in it updating
their favorite ebuilds and developers with CVS access making sure all
new ebuilds going into the tree follow the scheme.

I feel bugzilla getting a tad busy in a couple weeks ;)

-- 

Bruce A. Locke
blocke@shivan.org

Re: [gentoo-dev] prefix overide portage

[Gert Menke]

Hi,

On Wed, Feb 20, 2002 at 05:07:48AM -0500, Bruce A. Locke wrote:
> On Wed, 2002-02-20 at 02:02, Matt Doughty wrote:
> > I personally would like to leave /bin,/sbin,/lib /usr/bin,/usr/lib,
> > and /usr/sbin alone after the initial bootstrap. I don't want 
> > optional packages to intermingle in the same file space as those
> > that are needed for the system to function.
The files that are needed for the system to run should not be in /usr at
all. System files go to /bin, /lib, /sbin, etc.
/usr contains the applications for, well, the users.

Probably just my personal preferences.

Greetings
Gert

Re: [gentoo-dev] prefix overide portage

[Matt Doughty]

On Wed, Feb 20, 2002 at 05:07:48AM -0500, Bruce A. Locke wrote:
> On Wed, 2002-02-20 at 02:02, Matt Doughty wrote:
> > Portage packages: leaving the default to /usr is fine, but I would
> >      really think that shouldn't become a dumping ground like it has
> >      in so many other distros.  I can understand those who don't care
> >      can leave it in default dumping ground mode, and still allow
> >      those of us who like a "cleaner" solution to have our way.
> 
> Yes its a matter of personal preference.  Personally I hated fbsd's use
> of /usr/local and the filesystem looked quite cluttered and unorganized
> (ditto goes for Solaris).  But it is a matter of personal preference.

Yeah so do I. I prefer the NetBSD usage of /usr/pkg. I reserve 
/usr/local for things I compile by hand. ;)
> 
> > I personally would like to leave /bin,/sbin,/lib /usr/bin,/usr/lib,
> > and /usr/sbin alone after the initial bootstrap. I don't want 
> > optional packages to intermingle in the same file space as those
> > that are needed for the system to function.  The ability to create
> > a clean delineation is doing the right thing(TM) from my perspective.
> 
> Again a preference.  I don't share your view as there is no technical
> basis for the view in my opinion.  There is no /usr/src in gentoo and no
> seperation between "core" and "optional".  But there should be nothing
> to stop you from doing what you want :)

Well yes there are technical arguements for it. Much like the 
specification of a small root because small file systems are
less prone to file corruption, the same logic apply to /usr.
Basically, since /usr/bin supplies your basic tools col, awk,
gcc etc. it is needed to have a fully functional base system,
and should be protected via a small partition size, and largely
static nature(I should be able to mount it ro for added protection).
Its just that the technical arguments obviously don't apply in your
situation.  One other technical reason is if you want to mount all
the large packages over NFS, but want a fully functioning base system
without network access. As for me its a matter of not liking the
clutter, and being an old stoggy bastard which isn't technical reason
I wouldn't suppose. ;)
>  
> > I think this really ammounts to good engineering, and if the goal is
> > to be more flexible than the ports/pkgsrc system this is needed
> > functionality.
> 
> Agreed.

Great! I like agreement. :) 
>  
> > On a related note, I think it would be wise to clearly delineate 
> > packages that are needed for basic booting system in some way. If
> > this functionality already exists, and I missed it please let me
> > know.
> 
> Gentoo supports the concept of profiles.   Much more powerful then a
> simply marking something as "core", etc :)
> 
> See /usr/portage/profiles/default-1.0_rc6/packages and the portage
> source code for more information.

Ok thanks for the headsup I will check that out.

> 
> >  My main thought here is I want the ability to rebuild the
> > base system readily. Actually the more I think of it the better it
> > would be if one could say bootstrap a system to test directory first
> > (maybe /usr/local/base-test) and then assuming a possibly even chrooting
> > to test the new base simply reinstall the proper place or rerun the
> > bootstap without the overridden directory.
> 
> You can (kinda) do that already though its not as elegant as having a
> relocatable prefix.  You could grab our build tarball from the website,
> untar it into a directory, chroot it, and follow steps similar to those
> outlined in the install guide.  If you want to play around with usermode
> linux, just toss the tarball on a loopback filesystem and go from there
> :)

Yeah, I knew I could work around it.  I was just thinking that would be
nice functionality to have at some point.

> 
> > One way or another the 
> > ability to override the target for a package has many practical
> > applications.  Once again, let me know what I can do to help with this.
> 
> >From my understanding we'd need some variables defined in /etc/make.conf
> or /etc/make.globals (with current behaviors as the default) and support
> in portage to override these variables on a per package basis from the
> comamnd line.  Does portage already have this functionality in
> 1.8.9-pre*?
> 
> After that it would be a matter of people interested in it updating
> their favorite ebuilds and developers with CVS access making sure all
> new ebuilds going into the tree follow the scheme.
> 
> I feel bugzilla getting a tad busy in a couple weeks ;)
> 

hee-hee, I will update alot of ebuilds. I'll sort of holding off any
heavy install until I can do that actually.

--Matt

Re: [gentoo-dev] prefix overide portage

[Daniel Robbins]

On Tue, 2002-02-19 at 22:02, Arcady Genkin wrote:
> > It should't be too much effort to let loose some scripts on the
> > portage tree to fix --preifx=/usr to --preifx=$SOME_PREFIX_VAR where
> > the SOME_PREFIX_VAR can be set in /etc/make.conf.
> 
> There's more to it than that, but, arguably, nothing that cannot be
> done.

I don't have a problem supporting this, as long as relocatable ebuilds
are actually tested and not just assumed to work.  What % of srpms
support relocation anyway?

Best Regards,

-- 
Daniel Robbins                                  <drobbins@gentoo.org>
Chief Architect/President                       http://www.gentoo.org 
Gentoo Technologies, Inc.

Re: [gentoo-dev] prefix overide portage

[Dave Lee]

Daniel Robbins wrote:
> On Tue, 2002-02-19 at 22:02, Arcady Genkin wrote:
> > > It should't be too much effort to let loose some scripts on the
> > > portage tree to fix --preifx=/usr to --preifx=$SOME_PREFIX_VAR where
> > > the SOME_PREFIX_VAR can be set in /etc/make.conf.
> > 
> > There's more to it than that, but, arguably, nothing that cannot be
> > done.
> 
> I don't have a problem supporting this, as long as relocatable ebuilds
> are actually tested and not just assumed to work.  What % of srpms
> support relocation anyway?

srpms or rpms?  if you use an srpm to build an rpm for your own use then 
you can easily specify configure paths in your .rpmmacros file (I used to 
do this), assuming the rpm spec file hasnt hard coded the configure paths,
which is essential what we are talking about here with portage.  on the
other hand most rpm based distro will only seem to build and ship rpms
that aren't relocatable. of course when you install and rpm you could
always --force (I think) or --relocate --badreloc.

Dave

Re: [gentoo-dev] prefix overide portage

[Bruce A. Locke]

On Tue, 2002-02-19 at 23:38, Dave Lee wrote:

> I don't think this would actually be "hacking", I would call it something
> much nicer, like cleaning up.

Hacking as in trying to "hack around in" an autogenerated script that
quite frankly wasn't meant for humans to edit it, or having to
autogenerate our own configure scripts using a system few people really
understand :)

I do think "hacking" is the correct term here ;)

> I can see the desire to set a custom
> install prefix, and I think that making the ebuild scripts more flexible
> to allow for this may prove useful in that it will make the portage system
> much more flexible and customizable.  It should't be too much effort to
> let loose some scripts on the portage tree to fix --preifx=/usr to
> --preifx=$SOME_PREFIX_VAR where the SOME_PREFIX_VAR can be set in 
> /etc/make.conf.  In another thread Vitaly Kushneriuk said "the Gentoo way 
> is to provide user with the maximum control that is practical" and I dont
> think having a custom prefix would be impractical.  Anyway, just my
> thoughts on the subject.  One thing to note is that I noticed the ebuild
> system is "rigid" like this in more ways than just preifx, every other
> configure variable is hardcoded by the ebuild author into the ebuild file,
> like mandir and others.  In rpm systems, when you create an rpm spec, you
> can use %{_prefix} and %{_mandir} when you build rpms, and that gives it
> some flexibility.

Agreed, it would be a nice addition.  It would help if someone
associated with portage would add relavent support to portage or at
least set an example as a standard.  This means we could make sure all
new packages follow it and we can phase it into older packages over time
as we update them for other reasons.

-- 

Bruce A. Locke
blocke@shivan.org