Re: [gentoo-dev] FHS compliance

[Sebastian Werner <sebastian@werner-productions.de>]

Am Don, 2002-02-07 um 22.40 schrieb George Shapovalov:
> I would feel uneasy having package database sitting in /var (people quite 
> often allocate separate partition for that one to get some protection for the 
> rest of the system as this is the one, which changes most often).
> Well, in fact I am about /var/db/pkg. To me it was unnatural place to look 
> for the database of installed packages. I there would be a discussion I would 
> vote for keeping both portage and db/pkg trees under /usr.
> 
> George
> 

I would like something like:

/usr/portage/* -> /usr/share/portage/available
/var/db/pkg/* -> /usr/share/portage/installed
/usr/portage/profiles -> /usr/share/portage/profiles
/usr/portage/distfiles -> /usr/share/portage/archives

And the flat hierarchy (as one mails before) of packages in both
directories: available and installed!

Greetings 

Sebastian



> 
> On Thursday 07 February 2002 08:32, you wrote:
> > I assume the reason that portage is in /usr and db/pkg is in
> > /var is that that is where FreeBSD puts ports and db/pkg.
> > Of course FreeBSD doesn't have any reason to worry about
> > FHS compliance.  Since I am compulsive about having up to
> > date versions of everything I mount /usr rw, so this is not
> > an issue for me personally.
> >
> > > Chris Moore wrote:                    [Sat Feb  2 2002,  3:42:32AM EST]
> > >
> > > > Move the portage package ebuild filetree from /usr/portage to
> > > > /var/lib/portage ( See 5.8.3 +-<pkgtool> and cross reference the
> > > > purposes of the /usr hierarchy with the purpose of /var which is
> > > > summarized as follows: /usr's purpose is shareable read-only data
> > > > (ebuilds are updated!) /var's purpose is sharable/unsharable DYNAMIC
> > > > application data (such as the ebuild dirtree) and /var/lib has the
> > > > specific option for the package tool's dynamic data)
> > >
> > > I'm not sure that the ebuild dirtree should be considered 'dynamic'.
> > > The only time it *needs* to be updated (written) is shortly before doing
> > > a merge.  Since the merge is going to be going around writing stuff in
> > > the /usr tree anyway, updating /usr/portage doesn't seem that bad.  I
> > > haven't settled on a personal opinion yet, so I'm mostly playing devil's
> > > advocate here.
> > >
> > > Consider a normal case where /usr is actually mounted r/o, such as on a
> > > local network of machines where most of the machines mount /usr
> > > read-only from a remote file server.  In this case, none of these
> > > subordinate machines would need to update /usr/portage.  If you wanted
> > > to install new software, you would do so on the file server where
> > > /usr/bin, /usr/lib, /usr/portage, etc. are all mounted r/w, and
> > > therefore you could do the 'emerge rsync' as well package merges.
> > >
> > > Now that I think about it, this same argument would apply to
> > > /var/db/pkg, though, so I guess to be consistant the two (/usr/portage
> > > and /var/db/pkg) should be in the same place.  Do they both belong in
> > > /usr?
> > >
> > > --Chouser
> > > _______________________________________________
> > > gentoo-dev mailing list
> > > gentoo-dev@gentoo.org
> > > http://lists.gentoo.org/mailman/listinfo/gentoo-dev
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
-- 
Sebastian Werner
-
http://www.werner-productions.de
sebastian@werner-productions.de
-
Bismarckstraße 51
32427 Minden
-
Mobile: 0179.4590730


--------------------------------------------------------------------------------
QOTD:
	"It's hard to tell whether he has an ace up his sleeve or if
	the ace is missing from his deck altogether."