[gentoo-dev] /usr/portage --> /var/portage

[gentoo-dev] /usr/portage --> /var/portage

[Meder Bakirov]

Hi all!

I just wanted to ask: can we expect, in future versions of a Gentoo Linux, a 
move of /usr/portage to /var/portage as the most appropriate place to store 
frequently changing portage tree? 

I guess, it (Gentoo) would then suit most admins, willing to have a Gentoo 
Linux on their servers (I use Gentoo on my servers :-P). Because, for 
example, in my case, I have /usr always mounted ro (read-only) in fstab, 
remounting it rw (read-write) for critical updates only (when I emerge some 
new apps; e.g. security updates)

How does it intersect with FHS (Filesystem Hierarchy Standard)?

Thank you very much!

With the best regards,

Meder


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[Seemant Kulleen]

[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]

On Wed, 2004-01-14 at 22:48, Meder Bakirov wrote:
> Hi all!
> 
> I just wanted to ask: can we expect, in future versions of a Gentoo Linux, a 
> move of /usr/portage to /var/portage as the most appropriate place to store 
> frequently changing portage tree? 
> 
> I guess, it (Gentoo) would then suit most admins, willing to have a Gentoo 
> Linux on their servers (I use Gentoo on my servers :-P). Because, for 
> example, in my case, I have /usr always mounted ro (read-only) in fstab, 
> remounting it rw (read-write) for critical updates only (when I emerge some 
> new apps; e.g. security updates)
> 
> How does it intersect with FHS (Filesystem Hierarchy Standard)?
> 
> Thank you very much!
> 
> With the best regards,
> 
> Meder
> 
> 
> --
> gentoo-dev@gentoo.org mailing list

You can set PORTDIR to point your portage tree wherever you like.
-- 
Seemant Kulleen
Developer and Project Co-ordinator,
Gentoo Linux					http://dev.gentoo.org/~seemant

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] /usr/portage --> /var/portage

[Meder Bakirov]

On Thursday 15 January 2004 12:06, Seemant Kulleen wrote:
> On Wed, 2004-01-14 at 22:48, Meder Bakirov wrote:
> > Hi all!
> >
> > I just wanted to ask: can we expect, in future versions of a Gentoo
> > Linux, a move of /usr/portage to /var/portage as the most appropriate
> > place to store frequently changing portage tree?
> >
> > I guess, it (Gentoo) would then suit most admins, willing to have a
> > Gentoo Linux on their servers (I use Gentoo on my servers :-P). Because,
> > for example, in my case, I have /usr always mounted ro (read-only) in
> > fstab, remounting it rw (read-write) for critical updates only (when I
> > emerge some new apps; e.g. security updates)
> >
> > How does it intersect with FHS (Filesystem Hierarchy Standard)?
> >
> > Thank you very much!
> >
> > With the best regards,
> >
> > Meder
> >
> >
> > --
> > gentoo-dev@gentoo.org mailing list
>
> You can set PORTDIR to point your portage tree wherever you like.

Yes, I already do so now! :) But how about future versions of Gentoo Linux? 
Doesn't /var suits better (by default), than /usr in case of FHS? Or is it 
due to the BSD's fashion of storing ports in /usr/ports?

Thank you very much :)

With the best regards,

Meder


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[purslow]

040115 Meder Bakirov wrote:
> can we expect, in future versions of a Gentoo Linux,
> a move of /usr/portage to /var/portage as the most appropriate place
> to store frequently changing portage tree?
> Doesn't /var suits better (by default), than /usr in case of FHS?
> Or is it due to the BSD's fashion of storing ports in /usr/ports?

i'ld say this is an intelligent suggestion
& it does look as if  /portage  was put in  /usr  following BSD's approach.
it's never an adequate reply to say "That's just the way we do it",
so shdn't this be looked at seriously by the Gentoo devt team ?
after all, there is some portage material in  /var  already.

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[Jason Stubbs]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 15 January 2004 16:06, Seemant Kulleen wrote:
> On Wed, 2004-01-14 at 22:48, Meder Bakirov wrote:
> > I just wanted to ask: can we expect, in future versions of a Gentoo
> > Linux, a move of /usr/portage to /var/portage as the most appropriate
> > place to store frequently changing portage tree?
>
> You can set PORTDIR to point your portage tree wherever you like.

Just make sure to update the /etc/make.profile symlink.

- --
Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFABkMGosKAszmcBv4RAtOZAJ9StjN9OHljhqgCXdn0TPv9VjNhRgCfRAnf
+LoU+nyAmX57Vf7i5CeBDWs=
=iFNe
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[Georgi Georgiev]

maillog: 15/01/2004-16:36:35(+0900): Jason Stubbs types
> > You can set PORTDIR to point your portage tree wherever you like.
> 
> Just make sure to update the /etc/make.profile symlink.

Alternative:

echo "/var/portage /usr/portage auto auto,bind 0 0" >> /etc/fstab

-- 
/\   Georgi Georgiev   /\ I went to the race track once and bet on a   /\
\/    chutz@gg3.net    \/ horse that was so good that it took seven    \/
/\  +81(90)6266-1163   /\ others to beat him!                          /\

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[Thomas T. Veldhouse]

Georgi Georgiev wrote:
> maillog: 15/01/2004-16:36:35(+0900): Jason Stubbs types
>>> You can set PORTDIR to point your portage tree wherever you like.
>>
>> Just make sure to update the /etc/make.profile symlink.
>
> Alternative:
>
> echo "/var/portage /usr/portage auto auto,bind 0 0" >> /etc/fstab
>

But, as far as the filesystem appears, this would still be against the
standard (cd /usr/portage will still work) and thus, you may as well just
leave it in /usr/portage.

Tom Veldhouse


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

I think the original poster was more concerned about being able to RO
mount /usr than caring what the FHS states.

On Thu, 2004-01-15 at 09:09, Thomas T. Veldhouse wrote:
> Georgi Georgiev wrote:
> > maillog: 15/01/2004-16:36:35(+0900): Jason Stubbs types
> >>> You can set PORTDIR to point your portage tree wherever you like.
> >>
> >> Just make sure to update the /etc/make.profile symlink.
> >
> > Alternative:
> >
> > echo "/var/portage /usr/portage auto auto,bind 0 0" >> /etc/fstab
> >
> 
> But, as far as the filesystem appears, this would still be against the
> standard (cd /usr/portage will still work) and thus, you may as well just
> leave it in /usr/portage.
> 
> Tom Veldhouse
> 
> 
> --
> gentoo-dev@gentoo.org mailing list
-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a pengiun?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] /usr/portage --> /var/portage

[Meder Bakirov]

On Thursday 15 January 2004 19:27, Chris Gianelloni wrote:
> I think the original poster was more concerned about being able to RO
> mount /usr than caring what the FHS states.

You were wrong :)

http://www.samba.org/~cyeoh/fhs-2.3-beta.pdf

Chapter 2. The Filesystem --> Rationale

I'm concerned on benefits, FHS gives us ;)

>
> On Thu, 2004-01-15 at 09:09, Thomas T. Veldhouse wrote:
> > Georgi Georgiev wrote:
> > > maillog: 15/01/2004-16:36:35(+0900): Jason Stubbs types
> > >
> > >>> You can set PORTDIR to point your portage tree wherever you like.
> > >>
> > >> Just make sure to update the /etc/make.profile symlink.
> > >
> > > Alternative:
> > >
> > > echo "/var/portage /usr/portage auto auto,bind 0 0" >> /etc/fstab
> >
> > But, as far as the filesystem appears, this would still be against the
> > standard (cd /usr/portage will still work) and thus, you may as well just
> > leave it in /usr/portage.
> >
> > Tom Veldhouse
> >
> >
> > --
> > gentoo-dev@gentoo.org mailing list


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[Philippe Coulonges]

Le Thu, 15 Jan 2004 11:48:24 +0500
Meder Bakirov <bakirov@transfer.kg> écrivait :

> in my case, I have /usr always mounted ro (read-only) in fstab, 
> remounting it rw (read-write) for critical updates only (when I emerge
> some new apps; e.g. security updates)

Do you mean that you frequently rsync your portage tree just for fun on
your servers ?

I don't see why portage should change in a context where you don't
intend to upgrade. And if you upgrade, you'll have to mount your /usr rw
anyway.

CU
CPHIL
-- 
User:       I'm having problems with my text editor.
Help desk:  Which editor are you using?
User:       I don't know, but it's version VI (pronounced: 6).
Help desk:  Oh, then you should upgrade to version VIM (pronounced:
994).

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[Jeremy Maitin-Shepard]

Philippe Coulonges <cphil@cphil.net> writes:

> [snip]

> Do you mean that you frequently rsync your portage tree just for fun on
> your servers ?

> I don't see why portage should change in a context where you don't
> intend to upgrade. And if you upgrade, you'll have to mount your /usr rw
> anyway.

More importantly, however, one purpose of having /var on a separate
partition is to limit fragmentation of /usr and the rest of the
filesystem.  Because of the nature of the portage tree (many small
files, frequent changes and frequent addition and removal of files), it
leads to fragmentation and therefore is better suited for /var.

-- 
Jeremy Maitin-Shepard

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[Matthew Kennedy]

Meder Bakirov <bakirov@transfer.kg> writes:

> Hi all!
>
> I just wanted to ask: can we expect, in future versions of a Gentoo Linux, a 
> move of /usr/portage to /var/portage as the most appropriate place to store 
> frequently changing portage tree? 
>
> I guess, it (Gentoo) would then suit most admins, willing to have a Gentoo 
> Linux on their servers (I use Gentoo on my servers :-P). Because, for 
> example, in my case, I have /usr always mounted ro (read-only) in fstab, 
> remounting it rw (read-write) for critical updates only (when I emerge some 
> new apps; e.g. security updates)
>
> How does it intersect with FHS (Filesystem Hierarchy Standard)?

[...]

This has been on of those minor complaints I have personally.

IMHO we should go with the following as a default:

    /usr/portage/packages -> /var/cache/packages
    /usr/portage -> /usr/share/portage

For /usr/portage/distfiles, I'm not sure.  Since it is essentially
architecture independent, I believe the following is appropriate:

    /usr/portage/distfiles -> /usr/share/portage/distfiles

I think the above is in-line with the Linux FHS.

Matt

-- 
Matthew Kennedy
Gentoo Linux Developer


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[Jeremy Maitin-Shepard]

Matthew Kennedy <mkennedy@gentoo.org> writes:

> [snip]

> This has been on of those minor complaints I have personally.

> IMHO we should go with the following as a default:

>     /usr/portage/packages -> /var/cache/packages
>     /usr/portage -> /usr/share/portage

I agree packages should go to /var/cache/, but perhaps in a
subdirectory in /var/cache/portage, such as
/var/cache/portage/packages.

The portage ebuild tree also qualifies as cache data, however, since it
is just a local mirror of the CVS repository (via rsync).  Furthermore,
as I have previously stated, it is useful to store it on /var because
it changes frequently, and thus tends to fragment the filesystem on
which it resides.

Likewise, the distfiles directory is also cache data, and will also
lead to fragmentation.

As far as the argument that there is no reason to want to keep /usr
mounted read-only and still update the portage tree, one reason might
be that portage is useful for determining if there is something to
update, and so someone might want to use portage to determine that, and
then only remount /usr as read-write when actually updating.  Someone
might also want to build packages without installing them.

-- 
Jeremy Maitin-Shepard

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[Drake Wyrm]

[-- Attachment #1: Type: text/plain, Size: 3344 bytes --]

On Thu, Jan 15, 2004 at 04:54:24PM -0500, in <874quwyj1r.fsf@jbms.ath.cx>, Jeremy Maitin-Shepard <jbms@gentoo.org> wrote:
> Matthew Kennedy <mkennedy@gentoo.org> writes:
> > IMHO we should go with the following as a default:
> 
> >     /usr/portage/packages -> /var/cache/packages
> >     /usr/portage -> /usr/share/portage
> 
> I agree packages should go to /var/cache/, but perhaps in a
> subdirectory in /var/cache/portage, such as
> /var/cache/portage/packages.
> 
> The portage ebuild tree also qualifies as cache data, however, since it
...snip...

My two yen:

'/usr/portage' is the wrong place for the Portage tree. The data is
certainly sharable, but certainly *not* static. Furthermore, FHS states
"Large software packages must not use a direct subdirectory under the
/usr hierarchy." The Portage tree should be moved, for FHS compliance,
for the reasons listed in the FHS rationale, and for the reasons discussed
elsewhere in this thread.

But to where?

The catch is this: if the machine in question is running on a network that
actually *shares* its sharable data (e.g. the /usr hierarchy), it makes
sense to put the the Portage tree somewhere under /usr. Except during sync
operations (which would be performed by the host serving the /usr tree),
the Portage tree remains generally unmodified, so it fits the requirement
of "...read-only data ... must not be written to." Even though many
files in the Portage tree are architecture-specific, _the_tree_itself_
is architecture- and host-independent.

Unfortunately, a Gentoo machine is a very dynamic environment. The Portage
tree changes drastically and often. On a machine which maintains its own
Portage tree, '/var' is absolutely the right place to look. FHS provides
two likely options: '/var/cache' (application cache data) and '/var/lib'
(variable state data). The DISTDIR, on the other hand, is much less
dynamic and could still find a home under '/usr'.

The latest version of FHS also provides another beautiful option:
'/srv'. The intent of this addition seems to be a "/home" tree for
"users" that are really services/daemons. Something to keep in mind when
we start upgrading to the new FHS.

I propose the following be adopted as "reasonable defaults" for Portage.
PORTDIR=/var/cache/portage         # change to /usr/share/portage on
                                   # a network which shares /usr
DISTDIR=/usr/src/distfiles
PKGDIR=/usr/share/package/portage  # Any suggestions on pkgdir and rpmdir?
RPMDIR=/usr/share/package/rpm      # These don't seem quite right
PORTAGE_TMPDIR=/var/tmp
PORT_LOGDIR=/var/log/portage

Also, move the contents of '/var/cache/edb' and '/var/db/pkg' to
'/var/lib/portage'. FHS specifically mentions '/var/db' as a BSDism
that should be moved to '/var/lib'; '/var/cache/edb' contains state
data, rather than cache data. This change should not be too difficult
to effect. Only 57 lines of code specifically mention '/var/cache/edb'
and 75 mention '/var/db'. To be painfully honest, there are a number of
Python constructs I do not yet understand, but I think I have a reasonable
grasp of how Portage actually works.

-- 
Batou: Hey, Major... You ever hear of "human rights"?
Kusanagi: I understand the concept, but I've never seen it in action.
  --Ghost in the Shell

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] /usr/portage --> /var/portage

[Jeremy Maitin-Shepard]

I agree with most of your suggestions.

As far as DISTDIR, however, it may be less dynamic, but that is largely
due to the lack of a convenient way to delete only the unneeded files,
which, if done, would result in a fair amount of hard disk
fragmentation.  Furthermore, it is still cache data.

As far as PORTDIR being moved to /usr/share when /usr is shared over a
network, I do not believe that would generally be useful, because if
/usr is shared, building is not going to be done except on a single
machine, and so there is no need for all of the machines to have access
to the portage tree.

PKGDIR (and RPMDIR) are also cache data (generated by compiling the
source), and are furthermore relatively dynamic (thus more suitable for
/var, because they lead to fragmentation) on most systems that generate
them.

-- 
Jeremy Maitin-Shepard

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[Paul de Vrieze]

> On Thu, Jan 15, 2004 at 04:54:24PM -0500, in <874quwyj1r.fsf@jbms.ath.cx>,

> '/usr/portage' is the wrong place for the Portage tree. The data is
> certainly sharable, but certainly *not* static. Furthermore, FHS states
> "Large software packages must not use a direct subdirectory under the
> /usr hierarchy." The Portage tree should be moved, for FHS compliance,
> for the reasons listed in the FHS rationale, and for the reasons discussed
> elsewhere in this thread.
>
> But to where?
>
> The catch is this: if the machine in question is running on a network that
> actually *shares* its sharable data (e.g. the /usr hierarchy), it makes
> sense to put the the Portage tree somewhere under /usr. Except during sync
> operations (which would be performed by the host serving the /usr tree),
> the Portage tree remains generally unmodified, so it fits the requirement
> of "...read-only data ... must not be written to." Even though many
> files in the Portage tree are architecture-specific, _the_tree_itself_
> is architecture- and host-independent.
>
> Unfortunately, a Gentoo machine is a very dynamic environment. The Portage
> tree changes drastically and often. On a machine which maintains its own
> Portage tree, '/var' is absolutely the right place to look. FHS provides
> two likely options: '/var/cache' (application cache data) and '/var/lib'
> (variable state data). The DISTDIR, on the other hand, is much less
> dynamic and could still find a home under '/usr'.

I would like to add that actually not all of the data in /usr/portage is
dispensible. If the profile directory is removed, emerge will not work (we
might be able to fix this). Further in the /var/cache/edb dir there are
files that are not caches in that sense of the word. They are also not
replaceable. So I think if we want to have this discussion we need to look
at all files that are involved in portage.

Paul


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[Jeremy Maitin-Shepard]

"Paul de Vrieze" <pauldv@gentoo.org> writes:

> I would like to add that actually not all of the data in /usr/portage is
> dispensible. If the profile directory is removed, emerge will not work (we
> might be able to fix this).

But it works well enough to run emerge sync, which restores the profile
directory.

> Further in the /var/cache/edb dir there are files that are not caches
> in that sense of the word. They are also not replaceable. So I think
> if we want to have this discussion we need to look at all files that
> are involved in portage.

Yes, the state data in /var/cache/edb should be in /var/lib, and the
world file should be in /etc (or /var/lib).

-- 
Jeremy Maitin-Shepard

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[Drake Wyrm]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

On Mon, Jan 19, 2004 at 10:26:40AM -0500, in <87ad4kt0wf.fsf@jbms.ath.cx>,
Jeremy Maitin-Shepard <jbms@gentoo.org> wrote:
> "Paul de Vrieze" <pauldv@gentoo.org> writes:
> > Further in the /var/cache/edb dir there are files that are not caches
> > in that sense of the word. They are also not replaceable. So I think
> > if we want to have this discussion we need to look at all files that
> > are involved in portage.
> 
> Yes, the state data in /var/cache/edb should be in /var/lib, and the
> world file should be in /etc (or /var/lib).
I would have to argue against putting the world file in /etc. Portage
updates it according to what has been installed; it is not a static
configuration file. Try adding a package to your world file and running
'emerge --world'.

Anybody recall why the Portage state data was split between /var/db/pkg
and /var/cache/edb (since Paul mentioned looking at all the files
involved)? I would like to understand the reasons behind the original
decisions before I develop any strong opinions.

-- 
Batou: Hey, Major... You ever hear of "human rights"?
Kusanagi: I understand the concept, but I've never seen it in action.
  --Ghost in the Shell

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] /usr/portage --> /var/portage

[Jeremy Maitin-Shepard]

Drake Wyrm <wyrm@haell.com> writes:

> On Mon, Jan 19, 2004 at 10:26:40AM -0500, in <87ad4kt0wf.fsf@jbms.ath.cx>,
> Jeremy Maitin-Shepard <jbms@gentoo.org> wrote:
>> "Paul de Vrieze" <pauldv@gentoo.org> writes:
>> > Further in the /var/cache/edb dir there are files that are not caches
>> > in that sense of the word. They are also not replaceable. So I think
>> > if we want to have this discussion we need to look at all files that
>> > are involved in portage.
>> 
>> Yes, the state data in /var/cache/edb should be in /var/lib, and the
>> world file should be in /etc (or /var/lib).
> I would have to argue against putting the world file in /etc. Portage
> updates it according to what has been installed; it is not a static
> configuration file. Try adding a package to your world file and running
> 'emerge --world'.

It is a user-configurable list of packages to update when one types
"emerge world."  In portage-ng, presumably multiple user-defined package
classes will be supported, as well additional options to specify whether
to prune entries from such files which would result in currently
uninstalled packages being installed, whether to add newly installed
packages to such files, and whether to install packages listed in such
files which are not currently installed.  With these features, such
files would become more like configuration files.

(IMHO, these package class files should not be treated particularly
different from specifying $(cat package-class-file) on the command-line.
Perhaps portage-ng will also support specifying an arbitrary file to use
as a package class, i.e. --file-list /path/to/list/of/packages.)

As far as the world file being modified by portage, there are programs
(mostly GUI) which modify their own configuration files.  Note that it
is user-configurable whether the world file is modified by portage.

> Anybody recall why the Portage state data was split between /var/db/pkg
> and /var/cache/edb (since Paul mentioned looking at all the files
> involved)? I would like to understand the reasons behind the original
> decisions before I develop any strong opinions.

Most of the data in /var/cache/edb is not state data -- it is mostly
cache data (all of the contents of the dep directory, and the virtuals
file).  Only the contents of config, counter, eclass.pickle, mtimedb,
repo.fails, repo.stats are state data.  The world file may have been
thought of as a kind of cache data (and it seems it still is, given
tools like regenworld), even though it is not.

-- 
Jeremy Maitin-Shepard

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[Drake Wyrm]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

On Mon, Jan 19, 2004 at 10:16:24AM +0100, in <52806.134.188.150.80.1074503784.squirrel@callisto.cs.kun.nl>, Paul de Vrieze <pauldv@gentoo.org> wrote:
> I would like to add that actually not all of the data in /usr/portage is
> dispensible. If the profile directory is removed, emerge will not work (we
> might be able to fix this). Further in the /var/cache/edb dir there are
> files that are not caches in that sense of the word. They are also not
> replaceable. So I think if we want to have this discussion we need to look
> at all files that are involved in portage.
I have some creepy ideas about how to improve profiles into meta-ebuilds
ala Gnome & KDE. I am currently cramming Python so I can be a bit less
of an armchair-developer. Which mailing list is used for Portage-ng
discussion?

-- 
Batou: Hey, Major... You ever hear of "human rights"?
Kusanagi: I understand the concept, but I've never seen it in action.
  --Ghost in the Shell

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] /usr/portage --> /var/portage

[Paul de Vrieze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 19 January 2004 23:27, Drake Wyrm wrote:
>
> I have some creepy ideas about how to improve profiles into
> meta-ebuilds ala Gnome & KDE. I am currently cramming Python so I can
> be a bit less of an armchair-developer. Which mailing list is used for
> Portage-ng discussion?

gentoo-portage-dev@gentoo.org

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFADO2CbKx5DBjWFdsRApx+AKC0TH97mjsDaudwXG4YNslK+HblDwCgjsnG
0FQJb4LjKdjelo0TQSy2tpY=
=yF2S
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[david]

On Tue, Jan 20, 2004 at 09:57:38AM +0100, Paul de Vrieze wrote:
> gentoo-portage-dev@gentoo.org
> 

what about discussion of catalyst ?

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[Eivind Tagseth]

* Matthew Kennedy <mkennedy@gentoo.org> [2004-01-15 13:29:45 -0600]:

> Meder Bakirov <bakirov@transfer.kg> writes:

> For /usr/portage/distfiles, I'm not sure.  Since it is essentially
> architecture independent, I believe the following is appropriate:
> 
>     /usr/portage/distfiles -> /usr/share/portage/distfiles
> 
> I think the above is in-line with the Linux FHS.

I'd like to see distfiles somewhere under /var.  I don't know if it's
just me, but I don't like distfiles/ to be continually growing with
source code for all packages, past and present.  So I clean my distfiles
directory using tmpreaper just as I do with /tmp.  This speaks for
/var IMO.



Eivind

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[Matthew Kennedy]

Eivind Tagseth <eivindt-gentoo@multinet.no> writes:

> * Matthew Kennedy <mkennedy@gentoo.org> [2004-01-15 13:29:45 -0600]:
>
>> Meder Bakirov <bakirov@transfer.kg> writes:
>
>> For /usr/portage/distfiles, I'm not sure.  Since it is essentially
>> architecture independent, I believe the following is appropriate:
>> 
>>     /usr/portage/distfiles -> /usr/share/portage/distfiles
>> 
>> I think the above is in-line with the Linux FHS.
>
> I'd like to see distfiles somewhere under /var.  I don't know if it's
> just me, but I don't like distfiles/ to be continually growing with

[...]

IIRC, thats not very standard -- but what do we care.  

/usr/share --> "share" means exactly that -- sharable!  It is sharable
because it is only supposed to contain architecture independent stuff.
You should be able to share /usr/share via NFS etc. to other machines,
and I can see that distfiles is a prime candidate for that.

Debian do a stellar job of keeping to this policy.

Having said that, you could make an argument for
/var/portage/distfiles etc. based on the fact that in a heterogeneous
environment, distfiles will contain a /few/ architecture-dependent
sources.

Matt

-- 
Matthew Kennedy
Gentoo Linux Developer


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[purslow]

040116 Matthew Kennedy wrote:
>  /usr/share  -->  "share"  means exactly that -- sharable
> because it is only supposed to contain architecture independent stuff.
> You should be able to share /usr/share via NFS etc. to other machines,

i always understood it to mean shareable among users on the system:
eg fonts & docs, which everyone wants access to.

moving all the Portage stuff  /usr  ->  /var  does seem to make sense
& correspond to FHS rules.

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[John Nilsson]

[-- Attachment #1: Type: text/plain, Size: 279 bytes --]

> i always understood it to mean shareable among users on the system:
> eg fonts & docs, which everyone wants access to.

A common missunderstanding is that usr means user. usr means unix system  
resources. (Mabey a rename to lsr,gsr or just sr might correct this?)

/John

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] /usr/portage --> /var/portage

[Jeremy Maitin-Shepard]

Matthew Kennedy <mkennedy@gentoo.org> writes:

> Eivind Tagseth <eivindt-gentoo@multinet.no> writes:
>> * Matthew Kennedy <mkennedy@gentoo.org> [2004-01-15 13:29:45 -0600]:
>> 
>>> Meder Bakirov <bakirov@transfer.kg> writes:
>> 
>>> For /usr/portage/distfiles, I'm not sure.  Since it is essentially
>>> architecture independent, I believe the following is appropriate:
>>> 
>>> /usr/portage/distfiles -> /usr/share/portage/distfiles
>>> 
>>> I think the above is in-line with the Linux FHS.
>> 
>> I'd like to see distfiles somewhere under /var.  I don't know if it's
>> just me, but I don't like distfiles/ to be continually growing with

> [...]

> IIRC, thats not very standard -- but what do we care.  

> /usr/share --> "share" means exactly that -- sharable!  It is sharable
> because it is only supposed to contain architecture independent stuff.
> You should be able to share /usr/share via NFS etc. to other machines,
> and I can see that distfiles is a prime candidate for that.

Yes, it is sharable, but it is also cache data.  So it could go in
either /usr/share or /var/cache, except that there are other benefits
to putting it on /var, namely fragmentation issues.  It is also useful
to note that in an environment where /usr/share is actually NFS shared,
most likely building of packages is only done on one or several
machines, and therefore there is no need for distfiles to be accessible
on all machines.

-- 
Jeremy Maitin-Shepard

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] /usr/portage --> /var/portage

[Phil Richards]

On 2004-01-15, Matthew Kennedy <mkennedy@gentoo.org> wrote:
>  For /usr/portage/distfiles, I'm not sure.  Since it is essentially
>  architecture independent, I believe the following is appropriate:
>      /usr/portage/distfiles -> /usr/share/portage/distfiles
>  I think the above is in-line with the Linux FHS.

/usr/portage/distfiles is most definitely cache data and should be
under /var/cache somewhere.  Given that it has no auto pruning facility
(wish list candidate!) it is the main reason why my /usr used to fill up,
which then breaks installation at install time, rather than build time.

(It is currently around 2GB on my system - I only periodically remember
to prune it :-(  Then again, I've moved it to /var already so that's ok.)

phil
-- 
change name before "@" to "phil" for email


--
gentoo-dev@gentoo.org mailing list