[gentoo-dev] [rfc] layman storage location (again)

[gentoo-dev] [rfc] layman storage location (again)

[Sebastian Pipping]

Hello!


By default layman currently stores overlays into

  /usr/local/portage/layman

(was /usr/portage/local/layman before that).
As of bug 253725 [1] that's not without problems.

I would like to get it right with the next switch.
Would

  /var/lib/layman

do well?  /var/cache/layman seems inadequate as it might not be
regenerated [2] without losses (as upstream moves along).

Would be great to hear a few opinions.  Thanks!



Sebastian


[1] https://bugs.gentoo.org/253725
[2] http://devmanual.gentoo.org/general-concepts/filesystem/index.html

Re: [gentoo-dev] [rfc] layman storage location (again)

[Jeremy Olexa]

On Fri, 15 Jan 2010 20:36:20 +0100, Sebastian Pipping <sping@gentoo.org>
wrote:
> Hello!
> 
> 
> By default layman currently stores overlays into
> 
>   /usr/local/portage/layman
> 
> (was /usr/portage/local/layman before that).
> As of bug 253725 [1] that's not without problems.

I don't think it should be changed again. It is quite annoying to have to
hunt down where the $next layman location is.

Why can't layman create /usr/local/portage/layman at runtime if it doesn't
exist and then you can remove the keepdir line from the ebuild??

-Jeremy

> 
> I would like to get it right with the next switch.
> Would
> 
>   /var/lib/layman
> 
> do well?  /var/cache/layman seems inadequate as it might not be
> regenerated [2] without losses (as upstream moves along).
> 
> Would be great to hear a few opinions.  Thanks!
> 
> 
> 
> Sebastian
> 
> 
> [1] https://bugs.gentoo.org/253725
> [2] http://devmanual.gentoo.org/general-concepts/filesystem/index.html

Re: [gentoo-dev] [rfc] layman storage location (again)

[Alex Legler]

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

On Fri, 15 Jan 2010 20:36:20 +0100, Sebastian Pipping
<sping@gentoo.org> wrote:

> Would
> 
>   /var/lib/layman
> 
> do well?

+1

-- 
Alex Legler | Gentoo Security / Ruby
a3li@gentoo.org | a3li@jabber.ccc.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [rfc] layman storage location (again)

[Dawid Węgliński]

On Friday 15 January 2010 20:44:43 Alex Legler wrote:
> >   /var/lib/layman
> >
> > do well?
> 
> +1
> 
-1, /usr/local/layman?
-- 
Cheers
Dawid Węgliński

Re: [gentoo-dev] [rfc] layman storage location (again)

[Jorge Manuel B. S. Vicetto]

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

On 15-01-2010 21:25, Dawid Węgliński wrote:
> On Friday 15 January 2010 20:44:43 Alex Legler wrote:
>>>   /var/lib/layman
>>>
>>> do well?
>>
>> +1
>>
> -1, /usr/local/layman?

Wouldn't that break the rule that /usr/local is reserved for users / admins?

- From the alternatives, /var/lib/layman doesn't sound right. If
/var/cache/layman doesn't work, what about /var/spool/layman instead?

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktQ+zsACgkQcAWygvVEyAJISgCcDCKsH7jIN07MVInTVkQftS6C
GV8An2qWhr3Kg67FNopOBZAe266VcDVj
=/6ng
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [rfc] layman storage location (again)

[Dawid Węgliński]

On Saturday 16 January 2010 00:33:15 Jorge Manuel B. S. Vicetto wrote:
> On 15-01-2010 21:25, Dawid Węgliński wrote:
> > On Friday 15 January 2010 20:44:43 Alex Legler wrote:
> >>>   /var/lib/layman
> >>>
> >>> do well?
> >>
> >> +1
> >
> > -1, /usr/local/layman?
> 
> Wouldn't that break the rule that /usr/local is reserved for users /
>  admins?
> 
> From the alternatives, /var/lib/layman doesn't sound right. If
> /var/cache/layman doesn't work, what about /var/spool/layman instead?
> 

Or just leave it up to user with elog message... Or ask him first to set 
variable in /etc/make.conf?

-- 
Cheers
Dawid Węgliński

Re: [gentoo-dev] [rfc] layman storage location (again)

[Ulrich Mueller]

>>>>> On Fri, 15 Jan 2010, Jorge Manuel B S Vicetto wrote:

> - From the alternatives, /var/lib/layman doesn't sound right.

The FHS (which we don't always obey, but in cases like this it's
useful as a guideline) says about /var/lib: "This hierarchy holds
state information pertaining to an application or the system. State
information is data that programs modify while they run, and that
pertains to one specific host."

IMHO that doesn't fit layman's usage case.

> If /var/cache/layman doesn't work,

It doesn't, since the data cannot be locally (i.e. off-line)
regenerated.

> what about /var/spool/layman instead?

Looks like it's the best location available in /var.

But by analogy, layman should store things in the same hierarchy where
the portage tree is, and that is under /usr. What was wrong with the
original location /usr/portage/local?

Ulrich

Re: [gentoo-dev] [rfc] layman storage location (again)

[Sebastian Pipping]

On 01/16/10 00:33, Jorge Manuel B. S. Vicetto wrote:
> - From the alternatives, /var/lib/layman doesn't sound right. If
> /var/cache/layman doesn't work, what about /var/spool/layman instead?

Okay, how about

  /var/spool/layman

then?  Any objections?



Sebastian

Re: [gentoo-dev] [rfc] layman storage location (again)

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 752 bytes --]

On Friday 15 January 2010 20:24:38 Sebastian Pipping wrote:
> On 01/16/10 00:33, Jorge Manuel B. S. Vicetto wrote:
> > - From the alternatives, /var/lib/layman doesn't sound right. If
> > /var/cache/layman doesn't work, what about /var/spool/layman instead?
> 
> Okay, how about
> 
>   /var/spool/layman
> 
> then?  Any objections?

/var/spool/ is a terrible idea -- these are not jobs being queued waiting to 
be processed by a daemon and then removed.

if you want to keep all of layman's stuff together, then about your only 
option is to create your own tree at like /var/layman/.  the better idea 
though would be to split your stuff along the proper lines.

cache files = /var/cache/layman/
config files = /etc/layman/
-mike

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

Re: [gentoo-dev] [rfc] layman storage location (again)

[Sebastian Pipping]

On 01/16/10 02:45, Mike Frysinger wrote:
> if you want to keep all of layman's stuff together, then about your only 
> option is to create your own tree at like /var/layman/.

anybody objecting to /var/layman ?


> the better idea 
> though would be to split your stuff along the proper lines.
> 
> cache files = /var/cache/layman/

as i said: it's not a "normal" cache.



sebastian

Re: [gentoo-dev] [rfc] layman storage location (again)

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 658 bytes --]

On Friday 15 January 2010 20:55:18 Sebastian Pipping wrote:
> On 01/16/10 02:45, Mike Frysinger wrote:
> > the better idea
> > though would be to split your stuff along the proper lines.
> >
> > cache files = /var/cache/layman/
> 
> as i said: it's not a "normal" cache.

you said but didnt explain why it's "special".  these are merely caches of 
external overlays and xml caches of overlay lists.  if people are concerned 
with pining a version, then they should be extracting to their own overlay 
since a mere sync is going to drop it (just like /usr/portage/).  if you want 
to call it state data, then it'd be /var/lib/layman/ ...
-mike

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

Re: [gentoo-dev] [rfc] layman storage location (again)

[Sebastian Pipping]

On 01/16/10 05:39, Mike Frysinger wrote:
> On Friday 15 January 2010 20:55:18 Sebastian Pipping wrote:
>> On 01/16/10 02:45, Mike Frysinger wrote:
>>> the better idea
>>> though would be to split your stuff along the proper lines.
>>>
>>> cache files = /var/cache/layman/
>>
>> as i said: it's not a "normal" cache.
> 
> you said but didnt explain why it's "special".  these are merely caches of 
> external overlays and xml caches of overlay lists.

to me cache is something that speeds up operation but does not hold
content of real value.  with layman overlay "checkouts" that's a bit
different.  let's say a host overlay is taken offline: now the layman
copy is my only source.  Page [1] describes /var/cache as
"Long term data which can be regenerated". so to me it's not a cache
because there might be data in there that we cannot regenerate.



sebastian


[1] http://devmanual.gentoo.org/general-concepts/filesystem/index.html

[gentoo-dev] Re: [rfc] layman storage location (again)

[Peter Hjalmarsson]

lör 2010-01-16 klockan 19:16 +0100 skrev Sebastian Pipping:
> On 01/16/10 05:39, Mike Frysinger wrote:
> > On Friday 15 January 2010 20:55:18 Sebastian Pipping wrote:
> >> On 01/16/10 02:45, Mike Frysinger wrote:
> >>> the better idea
> >>> though would be to split your stuff along the proper lines.
> >>>
> >>> cache files = /var/cache/layman/
> >>
> >> as i said: it's not a "normal" cache.
> > 
> > you said but didnt explain why it's "special".  these are merely caches of 
> > external overlays and xml caches of overlay lists.
> 
> to me cache is something that speeds up operation but does not hold
> content of real value.  with layman overlay "checkouts" that's a bit
> different.  let's say a host overlay is taken offline: now the layman
> copy is my only source.  Page [1] describes /var/cache as
> "Long term data which can be regenerated". so to me it's not a cache
> because there might be data in there that we cannot regenerate.
> 
> 
That is for the overlays, yeah?
But hov about the cache_*.xml files?

I think what he meant was that should layman really only has one
directory? One for cache (downloaded/downloadable lists of overlays?
in /var/cache/layman/?), one for the make.conf and overlay.xml
(/etc/layman/?) and maybe one more directory for the overlays
(/var/lib/layman/?).

That make.conf/overlay.xml may not go as cache, nor do the overlays
themselves, but as I said, should really it all be in the same
directory?

Re: [gentoo-dev] Re: [rfc] layman storage location (again)

[Sebastian Pipping]

On 01/16/10 19:52, Peter Hjalmarsson wrote:
> That is for the overlays, yeah?
> But hov about the cache_*.xml files?
> 
> I think what he meant was that should layman really only has one
> directory? One for cache (downloaded/downloadable lists of overlays?
> in /var/cache/layman/?), one for the make.conf and overlay.xml
> (/etc/layman/?) and maybe one more directory for the overlays
> (/var/lib/layman/?).
> 
> That make.conf/overlay.xml may not go as cache, nor do the overlays
> themselves, but as I said, should really it all be in the same
> directory?

yes, cache_*.xml are a bit different.  Would you benefit from a move of
these files to /var/chache/layman?



Sebastian

Re: [gentoo-dev] [rfc] layman storage location (again)

[Peter Volkov]

The bug you mentioned [253725] is not about layman location, it's only
about "keepdir" line. Why don't we fix that and don't change defaults
another time? Such change does more harm for our users then good.

В Сбт, 16/01/2010 в 02:55 +0100, Sebastian Pipping пишет:
> On 01/16/10 02:45, Mike Frysinger wrote:
> > if you want to keep all of layman's stuff together, then about your only 
> > option is to create your own tree at like /var/layman/.
> 
> anybody objecting to /var/layman ?

layman cache is nfs distributable. Also it's good idea to have it close
to PORTDIR. Thus I'd like to keep it somewhere at /usr.

It's just impossible to choose perfect location that suits all needs and
it should stay user-configurable. So again, do not change this default
we no real need another time, please.

-- 
Peter.

Re: [gentoo-dev] [rfc] layman storage location (again)

[Lars Wendler]

[-- Attachment #1: Type: Text/Plain, Size: 642 bytes --]


> It's just impossible to choose perfect location that suits all needs and
> it should stay user-configurable. So again, do not change this default
> we no real need another time, please.

/usr/local is a bad choice for an ebuild-generated default. Like I said in bug 
#253725 I don't want ebuilds to mess with stuff in /usr/local. So either remove 
this default completely and let the user decide when setting up layman or move 
it around.
The best suggestions I've read here for now were either /var/layman or 
/usr/layman which I would have no problem with.

-- 
Lars Wendler (Polynomial-C)
Gentoo Staffer and bug-wrangler

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

Re: [gentoo-dev] [rfc] layman storage location (again)

[Nirbheek Chauhan]

On Sat, Jan 16, 2010 at 4:41 PM, Lars Wendler <polynomial-c@gentoo.org> wrote:
>> It's just impossible to choose perfect location that suits all needs and
>> it should stay user-configurable. So again, do not change this default
>> we no real need another time, please.
>
> /usr/local is a bad choice for an ebuild-generated default. Like I said in bug
> #253725 I don't want ebuilds to mess with stuff in /usr/local. So either remove
> this default completely and let the user decide when setting up layman or move
> it around.
> The best suggestions I've read here for now were either /var/layman or
> /usr/layman which I would have no problem with.
>

/me throws in /usr/share/layman

OTOH, I really think /usr/local/layman is OK as long as it's
runtime-generated and not added by the ebuild. That should satisfy bug
253725, and prevent another painful location move. It also makes sense
from the "/usr/local is user/admin domain" since only running the
layman tool will cause those directories to be created.


-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] [rfc] layman storage location (again)

[Pacho Ramos]

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

El sáb, 16-01-2010 a las 17:16 +0530, Nirbheek Chauhan escribió:
> On Sat, Jan 16, 2010 at 4:41 PM, Lars Wendler <polynomial-c@gentoo.org> wrote:
> >> It's just impossible to choose perfect location that suits all needs and
> >> it should stay user-configurable. So again, do not change this default
> >> we no real need another time, please.
> >
> > /usr/local is a bad choice for an ebuild-generated default. Like I said in bug
> > #253725 I don't want ebuilds to mess with stuff in /usr/local. So either remove
> > this default completely and let the user decide when setting up layman or move
> > it around.
> > The best suggestions I've read here for now were either /var/layman or
> > /usr/layman which I would have no problem with.
> >
> 
> /me throws in /usr/share/layman
> 
> OTOH, I really think /usr/local/layman is OK as long as it's
> runtime-generated and not added by the ebuild. That should satisfy bug
> 253725, and prevent another painful location move. It also makes sense
> from the "/usr/local is user/admin domain" since only running the
> layman tool will cause those directories to be created.
> 

From my (layman user) point of view I am still using /usr/portage/local
for it because I prefer to have all "portage trees" in the same place.
Maybe another option could be to have a /usr/portage/overlays directory
used for "unofficial" overlays, then, layman configuration stuff (like
its make.conf and so) could be present under /etc/layman, while overlays
(sunrise, gnome...) could be installed under /usr/portage/overlays


[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [rfc] layman storage location (again)

[Ben de Groot]

2010/1/16 Peter Volkov <pva@gentoo.org>:
> layman cache is nfs distributable. Also it's good idea to have it close
> to PORTDIR. Thus I'd like to keep it somewhere at /usr.

I'd like both to be under /var/

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
______________________________________________________

Re: [gentoo-dev] [rfc] layman storage location (again)

[dev-random]

On Sat, Jan 16, 2010 at 01:57:38PM +0100, Ben de Groot wrote:
> 2010/1/16 Peter Volkov <pva@gentoo.org>:
> > layman cache is nfs distributable. Also it's good idea to have it close
> > to PORTDIR. Thus I'd like to keep it somewhere at /usr.
> 
> I'd like both to be under /var/
> 

I _use_ both under /var/. In my config PORTDIR_OVERLAY="/var/repos/{many
directories}" and PORTDIR="/var/repos/gentoo". /usr/ is too crazy place
for ebuilds. IMHO.

[gentoo-dev] Re: [rfc] layman storage location (again)

[Jörg Schaible]

dev-random@mail.ru wrote:

> On Sat, Jan 16, 2010 at 01:57:38PM +0100, Ben de Groot wrote:
>> 2010/1/16 Peter Volkov <pva@gentoo.org>:
>> > layman cache is nfs distributable. Also it's good idea to have it close
>> > to PORTDIR. Thus I'd like to keep it somewhere at /usr.
>> 
>> I'd like both to be under /var/
>> 
> 
> I _use_ both under /var/. In my config PORTDIR_OVERLAY="/var/repos/{many
> directories}" and PORTDIR="/var/repos/gentoo". /usr/ is too crazy place
> for ebuilds. IMHO.

Same for me. I have PORTDIR also beneath /var ...

- Jörg

[gentoo-dev] Re: [rfc] layman storage location (again)

[Peter Hjalmarsson]

lör 2010-01-16 klockan 19:31 +0100 skrev Jörg Schaible:
> dev-random@mail.ru wrote:
> 
> > On Sat, Jan 16, 2010 at 01:57:38PM +0100, Ben de Groot wrote:
> >> 2010/1/16 Peter Volkov <pva@gentoo.org>:
> >> > layman cache is nfs distributable. Also it's good idea to have it close
> >> > to PORTDIR. Thus I'd like to keep it somewhere at /usr.
> >> 
> >> I'd like both to be under /var/
> >> 
> > 
> > I _use_ both under /var/. In my config PORTDIR_OVERLAY="/var/repos/{many
> > directories}" and PORTDIR="/var/repos/gentoo". /usr/ is too crazy place
> > for ebuilds. IMHO.
> 
> Same for me. I have PORTDIR also beneath /var ...
> 
> - Jörg
> 

Me too. I consider /usr/portage as one of those design flaws/thinkos
that are left behind since noone are ready to take the blame and flames
of all those who do not want to read elog-messages/announces and alike
and want to raise hell if somethings changes they are note prepared for.

Re: [gentoo-dev] Re: [rfc] layman storage location (again)

[Michael Higgins]

On Sat, 16 Jan 2010 19:57:39 +0100
Peter Hjalmarsson <xake@rymdraket.net> wrote:

> lör 2010-01-16 klockan 19:31 +0100 skrev Jörg Schaible:
> > dev-random@mail.ru wrote:
> > 
> > > On Sat, Jan 16, 2010 at 01:57:38PM +0100, Ben de Groot wrote:
> > >> 2010/1/16 Peter Volkov <pva@gentoo.org>:
> > >> > layman cache is nfs distributable. Also it's good idea to have
> > >> > it close to PORTDIR. Thus I'd like to keep it somewhere
> > >> > at /usr.
> > >> 
> > >> I'd like both to be under /var/
> > >> 
> > > 
> > > I _use_ both under /var/. In my config
> > > PORTDIR_OVERLAY="/var/repos/{many directories}" and
> > > PORTDIR="/var/repos/gentoo". /usr/ is too crazy place for
> > > ebuilds. IMHO.
> > 
> > Same for me. I have PORTDIR also beneath /var ...
> > 
> > - Jörg
> > 
> 
> Me too. I consider /usr/portage as one of those design flaws/thinkos
> that are left behind since noone are ready to take the blame and
> flames of all those who do not want to read elog-messages/announces
> and alike and want to raise hell if somethings changes they are note
> prepared for.
> 

Yes, PORTDIR default location under /usr was a totally stupid thing.
Please don't repeat it...

I have all portage under it's own partition, but /var/portage is
probably a more acceptable default, IMO.

-- 
 |\  /|        |   |          ~ ~  
 | \/ |        |---|          `|` ?
 |    |ichael  |   |iggins    \^ /
 michael.higgins[at]evolone[dot]org

Re: [gentoo-dev] Re: [rfc] layman storage location (again)

[Benedikt Böhm]

On Sat, Jan 16, 2010 at 8:38 PM, Michael Higgins <linux@evolone.org> wrote:
> Yes, PORTDIR default location under /usr was a totally stupid thing.
> Please don't repeat it...

One thing all you /usr naggers forget is, that /var cannot be shared
read-only via nfs (or bind mounts in case of virtual servers). most
single-machine users probably don't care, but there is more out there
than just your workstations. so putting portage into /usr is perfectly
valid. The only thing that violates the FHS is that "Large software
packages must not use a direct subdirectory under the /usr hierarchy."
A location beneath /usr/share probably would have been more compliant.

Anyway, since i'll keep my overlays in /usr/local regardless of the
outcome this thread has, i don't care :)

Bene

Re: [gentoo-dev] Re: [rfc] layman storage location (again)

[Sebastian Pipping]

On 01/16/10 23:46, Benedikt Böhm wrote:
> One thing all you /usr naggers forget is, that /var cannot be shared
> read-only via nfs (or bind mounts in case of virtual servers).

Why is that?  Please tell more.



Sebastian

Re: [gentoo-dev] Re: [rfc] layman storage location (again)

[Benedikt Böhm]

On Sun, Jan 17, 2010 at 12:55 AM, Sebastian Pipping <sping@gentoo.org> wrote:
> On 01/16/10 23:46, Benedikt Böhm wrote:
>> One thing all you /usr naggers forget is, that /var cannot be shared
>> read-only via nfs (or bind mounts in case of virtual servers).
>
> Why is that?  Please tell more.

Maybe you should actually read the FHS. You can of course share
specific subdirectories of /var read-only and still be compliant, but
/usr is specifically designed to be completely shareable read-only.

Re: [gentoo-dev] Re: [rfc] layman storage location (again)

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 687 bytes --]

On Saturday 16 January 2010 17:46:08 Benedikt Böhm wrote:
> On Sat, Jan 16, 2010 at 8:38 PM, Michael Higgins <linux@evolone.org> wrote:
> > Yes, PORTDIR default location under /usr was a totally stupid thing.
> > Please don't repeat it...
> 
> One thing all you /usr naggers forget is, that /var cannot be shared
> read-only via nfs (or bind mounts in case of virtual servers). most
> single-machine users probably don't care, but there is more out there
> than just your workstations. so putting portage into /usr is perfectly
> valid.

and good thing there is a config file for you to change it to suite your weird 
needs.  /var is a better default than /usr here.
-mike

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

Re: [gentoo-dev] [rfc] layman storage location (again)

[Ben de Groot]

2010/1/16 Sebastian Pipping <sping@gentoo.org>:
> On 01/16/10 02:45, Mike Frysinger wrote:
>> if you want to keep all of layman's stuff together, then about your only
>> option is to create your own tree at like /var/layman/.
>
> anybody objecting to /var/layman ?

I like that.

-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
______________________________________________________

Re: [gentoo-dev] [rfc] layman storage location (again)

[Sebastian Pipping]

On 01/16/10 13:56, Ben de Groot wrote:
>> anybody objecting to /var/layman ?
> 
> I like that.

it seems that

  /var/layman

is the only location nobody has objected to, yet.  i plan to go with
that atm.  /var/lib/layman is my second favorite.

again, any objections?



sebastian

Re: [gentoo-dev] [rfc] layman storage location (again)

[Nirbheek Chauhan]

On Sat, Jan 16, 2010 at 11:56 PM, Sebastian Pipping <sping@gentoo.org> wrote:
> it seems that
>
>  /var/layman
>
> is the only location nobody has objected to, yet.  i plan to go with
> that atm.  /var/lib/layman is my second favorite.
>
> again, any objections?
>

Why not make it a configuration option, with the default as
/var/layman (or whatever you want)? Then you can auto-generate it at
runtime easily, and everyone can use whatever they want. Just like
PORTDIR can be changed by anyone to anything they want.


-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] [rfc] layman storage location (again)

[Sebastian Pipping]

On 01/16/10 19:31, Nirbheek Chauhan wrote:
> Why not make it a configuration option, with the default as
> /var/layman (or whatever you want)?

It is configurable already (see /etc/layman/layman.cfg)

  #-----------------------------------------------------------
  # Defines the directory where overlays should be installed

  storage   : /path/to/somewhere

We're discussing the default only.



Sebastian

Re: [gentoo-dev] [rfc] layman storage location (again)

[Lars Wendler]

[-- Attachment #1: Type: Text/Plain, Size: 476 bytes --]

Am Samstag 16 Januar 2010 19:26:04 schrieb Sebastian Pipping:
> On 01/16/10 13:56, Ben de Groot wrote:
> >> anybody objecting to /var/layman ?
> >
> > I like that.
> 
> it seems that
> 
>   /var/layman
> 
> is the only location nobody has objected to, yet.  i plan to go with
> that atm.  /var/lib/layman is my second favorite.
> 
> again, any objections?
> 
> 
> 
> sebastian
> 

+1

-- 
Lars Wendler (Polynomial-C)
Gentoo Staffer and bug-wrangler


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

[gentoo-dev] Re: [rfc] layman storage location (again)

[Duncan]

Mike Frysinger posted on Fri, 15 Jan 2010 20:45:49 -0500 as excerpted:

> On Friday 15 January 2010 20:24:38 Sebastian Pipping wrote:
>> On 01/16/10 00:33, Jorge Manuel B. S. Vicetto wrote:
>> > - From the alternatives, /var/lib/layman doesn't sound right. If
>> > /var/cache/layman doesn't work, what about /var/spool/layman instead?
>> 
>> Okay, how about
>> 
>>   /var/spool/layman
>> 
>> then?  Any objections?
> 
> /var/spool/ is a terrible idea -- these are not jobs being queued
> waiting to be processed by a daemon and then removed.
> 
> if you want to keep all of layman's stuff together, then about your only
> option is to create your own tree at like /var/layman/.  the better idea
> though would be to split your stuff along the proper lines.
> 
> cache files = /var/cache/layman/
> config files = /etc/layman/

This looks pretty good to me, too.

1) Don't mess with /usr/local/, that's reserved for local use.

(FWIW, it's only because I'm lazy and use single-letter "p" for my 
portage dirs, that you didn't clash with anything I do, here.  But I 
/was/ wondering what the layman dir was doing in my local files!)

2) /etc/ (/etc/layman/, or as I use, /etc/portage/layman, but some folks 
may not like that) for config, but do keep in mind that some folks keep
/ (and thus /etc) read-only during normal operation.  Thus, you can't 
properly put your runtime-updated files there.

(It could of course be argued that layman updates should be done with 
gentoo tree updates, thus, during package manager updates, which aren't 
really normal operation since Gentoo at least depends on / and /etc being 
writable for package updates, but then you lose the flexibility of being 
able to update layman on its own, during otherwise normal operation.)

3) /var/spool/ isn't right either, because as someone else mentioned, 
these aren't files spooled for use by some daemon and then deletion.

4) That leaves some place in /var/cache or /var/lib, or possibly /usr 
(taking a cue from Gentoo's default /usr/portage), for your
runtime-updated files.

I don't personally much care which of those are used, but /usr/ itself 
may be read-only mounted as well during normal operation (with 
/usr/portage/ either on a different mountpoint, or the local gentoo tree 
stored elsewhere), so I'd suggest, unless you wish to use 
/usr/portage/layman, you don't use /usr/ at all, which leaves /var/lib/ 
or /var/cache/.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] [rfc] layman storage location (again)

[Antoni Grzymala]

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

Mike Frysinger dixit (2010-01-15, 20:45):

> On Friday 15 January 2010 20:24:38 Sebastian Pipping wrote:
> > On 01/16/10 00:33, Jorge Manuel B. S. Vicetto wrote:
> > > - From the alternatives, /var/lib/layman doesn't sound right. If
> > > /var/cache/layman doesn't work, what about /var/spool/layman instead?
> > 
> > Okay, how about
> > 
> >   /var/spool/layman
> > 
> > then?  Any objections?
> 
> /var/spool/ is a terrible idea -- these are not jobs being queued waiting to 
> be processed by a daemon and then removed.
> 
> if you want to keep all of layman's stuff together, then about your only 
> option is to create your own tree at like /var/layman/.  the better idea 
> though would be to split your stuff along the proper lines.
> 
> cache files = /var/cache/layman/
> config files = /etc/layman/

Layman-added trees are not much different altogether from the main
portage tree. Putting it in a location *totally* unrelated to the main
portage tree is, to put it mildly, *strange*. We still haven't heard in
this thread what was wrong with the original (${PORTDIR}/local/)
location. Despite all the propositions in the thread it still feels like
a best place to me. I'm sure the change to /usr/local/portage has been
discussed elsewhere previously, but maybe a pointer to some older
discussion would be handy.

I'm all for going back to the original location (based on ${PORTDIR}).

Best,

-- 
[a]

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

Re: [gentoo-dev] [rfc] layman storage location (again)

[Ben de Groot]

2010/1/15 Dawid Węgliński <cla@gentoo.org>:
> On Friday 15 January 2010 20:44:43 Alex Legler wrote:
>> >   /var/lib/layman
>> >
>> > do well?
>>
>> +1
>>
> -1, /usr/local/layman?

/usr/local/ is a location the system should avoid. Somewhere in /var/
seems to be the logical place.

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
______________________________________________________

Re: [gentoo-dev] [rfc] layman storage location (again)

[Antoni Grzymala]

Ben de Groot dixit (2010-01-16, 00:41):

> 2010/1/15 Dawid Węgliński <cla@gentoo.org>:
> > On Friday 15 January 2010 20:44:43 Alex Legler wrote:
> >> >   /var/lib/layman
> >> >
> >> > do well?
> >>
> >> +1
> >>
> > -1, /usr/local/layman?
> 
> /usr/local/ is a location the system should avoid. Somewhere in /var/
> seems to be the logical place.

I always thought /usr/portage/local was the logical place. If not, I'd
also say, that /var/layman/<whatever> makes sense.

-- 
[a]

Re: [gentoo-dev] [rfc] layman storage location (again)

[Fabian Groffen]

On 15-01-2010 20:36:20 +0100, Sebastian Pipping wrote:
> I would like to get it right with the next switch.
> Would
> 
>   /var/lib/layman
> 
> do well?  /var/cache/layman seems inadequate as it might not be
> regenerated [2] without losses (as upstream moves along).
> 
> Would be great to hear a few opinions.  Thanks!

How about storing it in DISTDIR (like metadata.xml)?  Or storing it
somewhere in the rsync image?  That would maybe make sense when Portage
takes over layman's functionality in the future.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] [rfc] layman storage location (again)

[Sebastian Pipping]

On 01/16/10 12:17, Fabian Groffen wrote:
> How about storing it in DISTDIR (like metadata.xml)?  Or storing it
> somewhere in the rsync image?

I'm not really sure what you have in mind.
Can you make it a bit more "visual" for me?



Sebastian

Re: [gentoo-dev] [rfc] layman storage location (again)

[Ciaran McCreesh]

2010/1/15 Sebastian Pipping <sping@gentoo.org>:
> By default layman currently stores overlays into
>
>  /usr/local/portage/layman
>
> (was /usr/portage/local/layman before that).
> As of bug 253725 [1] that's not without problems.
>
> I would like to get it right with the next switch.

I realise this is a lost cause, but... Repositories are databases, so
/var/db/ is your friend.

-- 
Ciaran McCreesh

Re: [gentoo-dev] [rfc] layman storage location (again)

[Sebastian Pipping]

On 01/17/10 10:01, Ciaran McCreesh wrote:
> I realise this is a lost cause, but... Repositories are databases, so
> /var/db/ is your friend.

Right, that's a way you can see it.

Does anyone _strongly_ prefer

  /var/db/layman

over

  /var/layman

?



Sebastian

Re: [gentoo-dev] [rfc] layman storage location (again)

[Thilo Bangert]

[-- Attachment #1: Type: Text/Plain, Size: 760 bytes --]

Ciaran McCreesh <ciaran.mccreesh@googlemail.com> said:
> I realise this is a lost cause, but... Repositories are databases, so
> /var/db/ is your friend.
> 

i like it. Closely followed by /var/lib/layman...

wikipedia says in 
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

/var/lib/
  State information. Persistent data modified by programs as they run, 
e.g., databases, packaging system metadata, etc.

/var/layman i dislike due to this sentence in the FHS:

   "Applications must generally not add directories to the top level of 
/var. Such directories should only be added if they have some system-wide 
implication[...]"

IMHO layman does not qualify. i am not religious on these things, however.
kind regards
Thilo

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

Re: [gentoo-dev] [rfc] layman storage location (again)

[Sebastian Pipping]

On 01/17/10 21:31, Thilo Bangert wrote:
> /var/layman i dislike due to this sentence in the FHS:
> 
>    "Applications must generally not add directories to the top level of 
> /var. Such directories should only be added if they have some system-wide 
> implication[...]"

isn't a package tree somehow having "system-wide implications"?
i'm not really sure about /var/db - doesn't seem to be in FHS.
is a package tree a database?

current ranking through my eyes:

1) /var/layman       con: adds folder to /var, maybe should not
2) /var/db/layman    con: you tell me
3) /var/lib/layman   con: not really /var/lib-style data



sebastian

Re: [gentoo-dev] [rfc] layman storage location (again)

[Ulrich Mueller]

>>>>> On Mon, 18 Jan 2010, Sebastian Pipping wrote:

> isn't a package tree somehow having "system-wide implications"?
> i'm not really sure about /var/db - doesn't seem to be in FHS.
> is a package tree a database?

This depends on your definition of "database". At least some parts of
the tree (like the files/ dirs) at not very database-like.

> current ranking through my eyes:

> 1) /var/layman       con: adds folder to /var, maybe should not
> 2) /var/db/layman    con: you tell me
> 3) /var/lib/layman   con: not really /var/lib-style data

I still think that it should be close to the portage tree, therefore
in /usr. But if you go for /var then take /var/layman.

Ulrich

[gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3

[Petteri Räty]

[-- Attachment #1.1: Type: text/plain, Size: 303 bytes --]

With GLEP 42 and proper logging of e* messages I think we shouldn't
annoy users any more with ebeep or epause so attached is a patch only
defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to
keep these around for EAPI 3? If not I will apply the attached patch.

Regards,
Petteri

[-- Attachment #1.2: deprecate-ebeep-epause.patch --]
[-- Type: text/plain, Size: 559 bytes --]

Index: eutils.eclass
===================================================================
RCS file: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v
retrieving revision 1.328
diff -u -r1.328 eutils.eclass
--- eutils.eclass	10 Jan 2010 15:58:58 -0000	1.328
+++ eutils.eclass	17 Jan 2010 20:37:05 -0000
@@ -19,6 +19,8 @@
 
 DESCRIPTION="Based on the ${ECLASS} eclass"
 
+if has "${EAPI:-0}" 0 1; then
+
 # @FUNCTION: epause
 # @USAGE: [seconds]
 # @DESCRIPTION:
@@ -49,6 +51,8 @@
 	fi
 }
 
+fi
+
 # @FUNCTION: ecvs_clean
 # @USAGE: [list of dirs]
 # @DESCRIPTION:

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3

[Tomáš Chvátal]

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

Dne 17.1.2010 21:38, Petteri Räty napsal(a):
> With GLEP 42 and proper logging of e* messages I think we shouldn't
> annoy users any more with ebeep or epause so attached is a patch only
> defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to
> keep these around for EAPI 3? If not I will apply the attached patch.
> 
> Regards,
> Petteri
++ should really not be used.

Actualy i think since it is just eclass call we could make it not used
anywhere in ebuilds, and then mark the functions as deprecated and just
return true.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktTd5wACgkQHB6c3gNBRYdHegCfZfD7r0aQUBH+ObWdjNvIDYAt
IE4AnjY655N8l7HwY4qZPh4Ms3pY8g4H
=5kRF
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3

[David Leverton]

On Sunday 17 January 2010 20:38:48 Petteri Räty wrote:
> With GLEP 42 and proper logging of e* messages I think we shouldn't
> annoy users any more with ebeep or epause so attached is a patch only
> defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to
> keep these around for EAPI 3? If not I will apply the attached patch.

The eclass-manpages comments should be updated too.

Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 532 bytes --]

On Sunday 17 January 2010 16:12:29 David Leverton wrote:
> On Sunday 17 January 2010 20:38:48 Petteri Räty wrote:
> > With GLEP 42 and proper logging of e* messages I think we shouldn't
> > annoy users any more with ebeep or epause so attached is a patch only
> > defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to
> > keep these around for EAPI 3? If not I will apply the attached patch.
> 
> The eclass-manpages comments should be updated too.

you mean you should re-emerge it on your system
-mike

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

[gentoo-dev] Re: RFC: don't define ebeep and epause in eutils in EAPI 3

[Torsten Veller]

* Mike Frysinger <vapier@gentoo.org>:
> On Sunday 17 January 2010 16:12:29 David Leverton wrote:
> > On Sunday 17 January 2010 20:38:48 Petteri Räty wrote:
> > > With GLEP 42 and proper logging of e* messages I think we shouldn't
> > > annoy users any more with ebeep or epause so attached is a patch only
> > > defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to
> > > keep these around for EAPI 3? If not I will apply the attached patch.

The patch only defines these functions for EAPI=0 and EAPI=1.

> > The eclass-manpages comments should be updated too.
> 
> you mean you should re-emerge it on your system

I think he means that the patch should modify @DESCRIPTION too.

Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3

[Petteri Räty]

[-- Attachment #1.1: Type: text/plain, Size: 553 bytes --]

On 01/17/2010 11:12 PM, David Leverton wrote:
> On Sunday 17 January 2010 20:38:48 Petteri Räty wrote:
>> With GLEP 42 and proper logging of e* messages I think we shouldn't
>> annoy users any more with ebeep or epause so attached is a patch only
>> defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to
>> keep these around for EAPI 3? If not I will apply the attached patch.
> 
> The eclass-manpages comments should be updated too.
> 

Updated patch. Will commit Wednesday unless there are objections.

Regards,
Petteri

[-- Attachment #1.2: deprecate-ebeep-epause.patch --]
[-- Type: text/plain, Size: 963 bytes --]

@@ -19,13 +19,15 @@

 DESCRIPTION="Based on the ${ECLASS} eclass"

+if has "${EAPI:-0}" 0 1 2; then
+
 # @FUNCTION: epause
 # @USAGE: [seconds]
 # @DESCRIPTION:
 # Sleep for the specified number of seconds (default of 5 seconds).  Useful when
 # printing a message the user should probably be reading and often used in
 # conjunction with the ebeep function.  If the EPAUSE_IGNORE env var is set,
-# don't wait at all.
+# don't wait at all. Defined in EAPIs 0 1 and 2.
 epause() {
        [[ -z ${EPAUSE_IGNORE} ]] && sleep ${1:-5}
 }
@@ -36,7 +38,7 @@
 # Issue the specified number of beeps (default of 5 beeps).  Useful when
 # printing a message the user should probably be reading and often used in
 # conjunction with the epause function.  If the EBEEP_IGNORE env var is set,
-# don't beep at all.
+# don't beep at all. Defined in EAPIs 0 1 and 2.
 ebeep() {
        local n
        if [[ -z ${EBEEP_IGNORE} ]] ; then
@@ -49,6 +51,8 @@
        fi
 }

+fi
+


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3

[Ulrich Mueller]

>>>>> On Sun, 17 Jan 2010, Petteri Räty wrote:

> With GLEP 42 and proper logging of e* messages I think we shouldn't
> annoy users any more with ebeep or epause

Agreed.

> so attached is a patch only defines these functions for EAPIs 0, 1
> and 2. Anyone have a reason to keep these around for EAPI 3?

We wouldn't gain much by this, because we still have to go through all
ebuilds using ebeep and epause and change them to EAPI 3.

This would be at least the same amount of work as removing the ebeep
and epause calls from all ebuilds. Why don't we do this instead and
leave the eclass as it is?

There are already enough differences between EAPIs for devs to learn,
and IMHO we shouldn't introduce additional complications such as EAPI
dependent eclass behaviour (except where necessary, e.g. src_prepare).

Ulrich

Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3

[Petteri Räty]

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

On 01/18/2010 10:07 AM, Ulrich Mueller wrote:
>>>>>> On Sun, 17 Jan 2010, Petteri Räty wrote:
> 
>> With GLEP 42 and proper logging of e* messages I think we shouldn't
>> annoy users any more with ebeep or epause
> 
> Agreed.
> 
>> so attached is a patch only defines these functions for EAPIs 0, 1
>> and 2. Anyone have a reason to keep these around for EAPI 3?
> 
> We wouldn't gain much by this, because we still have to go through all
> ebuilds using ebeep and epause and change them to EAPI 3.
> 

This would force people to upgrade when migrating to EAPI 3.

> This would be at least the same amount of work as removing the ebeep
> and epause calls from all ebuilds. Why don't we do this instead and
> leave the eclass as it is?
> 

This would make sure no-one uses these even in overlays.

> There are already enough differences between EAPIs for devs to learn,
> and IMHO we shouldn't introduce additional complications such as EAPI
> dependent eclass behaviour (except where necessary, e.g. src_prepare).
> 

Yes but as people shouldn't have the need for these there's not that
much to learn here.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3

[Tiziano Müller]

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

The proper replacement for such interactive notifications when called in
pkg_setup is pkg_pretend, which will (hopefully) be available in EAPI 4.
Thus I'd keep them around until then.

Cheers,
Tiziano

Am Sonntag, den 17.01.2010, 22:38 +0200 schrieb Petteri Räty:
> With GLEP 42 and proper logging of e* messages I think we shouldn't
> annoy users any more with ebeep or epause so attached is a patch only
> defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to
> keep these around for EAPI 3? If not I will apply the attached patch.
> 
> Regards,
> Petteri

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3551 bytes --]

Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3

[Petteri Räty]

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

On 01/18/2010 03:02 PM, Tiziano Müller wrote:
> The proper replacement for such interactive notifications when called in
> pkg_setup is pkg_pretend, which will (hopefully) be available in EAPI 4.
> Thus I'd keep them around until then.
> 
> Cheers,
> Tiziano
> 

ebeep or epause don't make your ebuild interactive.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3

[Peter Volkov]

В Втр, 19/01/2010 в 01:22 +0200, Petteri Räty пишет:
> On 01/18/2010 03:02 PM, Tiziano Müller wrote:
> > The proper replacement for such interactive notifications when called in
> > pkg_setup is pkg_pretend, which will (hopefully) be available in EAPI 4.
> > Thus I'd keep them around until then.

> ebeep or epause don't make your ebuild interactive.

True, but some ebuilds (e.g. tcpdump) do following:

ewarn "CAUTION !!! CAUTION !!! CAUTION"
ewarn "..."
ewarn "Press Ctrl+C to abort installation"
ebeep 5

And it's better to keep ebeep in such packages until pkg_pretend became
available.

-- 
Peter.

Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3

[Petteri Räty]

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

On 01/19/2010 10:37 AM, Peter Volkov wrote:
> В Втр, 19/01/2010 в 01:22 +0200, Petteri Räty пишет:
>> On 01/18/2010 03:02 PM, Tiziano Müller wrote:
>>> The proper replacement for such interactive notifications when called in
>>> pkg_setup is pkg_pretend, which will (hopefully) be available in EAPI 4.
>>> Thus I'd keep them around until then.
> 
>> ebeep or epause don't make your ebuild interactive.
> 
> True, but some ebuilds (e.g. tcpdump) do following:
> 
> ewarn "CAUTION !!! CAUTION !!! CAUTION"
> ewarn "..."
> ewarn "Press Ctrl+C to abort installation"
> ebeep 5
> 
> And it's better to keep ebeep in such packages until pkg_pretend became
> available.
> 

PROPERTIES="interactive" and really ask the user to proceed if it's
really that important.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[gentoo-dev] Re: [rfc] layman storage location (again)

[Peter Hjalmarsson]

mån 2010-01-18 klockan 06:27 +0100 skrev Ulrich Mueller:
> >>>>> On Mon, 18 Jan 2010, Sebastian Pipping wrote:
> 
> > isn't a package tree somehow having "system-wide implications"?
> > i'm not really sure about /var/db - doesn't seem to be in FHS.
> > is a package tree a database?
> 
> This depends on your definition of "database". At least some parts of
> the tree (like the files/ dirs) at not very database-like.
> 
> > current ranking through my eyes:
> 
> > 1) /var/layman       con: adds folder to /var, maybe should not
> > 2) /var/db/layman    con: you tell me
> > 3) /var/lib/layman   con: not really /var/lib-style data
> 
> I still think that it should be close to the portage tree, therefore
> in /usr. But if you go for /var then take /var/layman.
> 
> Ulrich
> 
> 

I sometimes think the main problem is the tree itself. Portage really
should had a directory of its own, but maybe with anoher structure,
like /var/portage, /var/portage/tree (the current
PORTDIR), /var/portage/distfiles (i.e. split out distfiles from the tree
itself), /var/portage/overlays/layman or /var/portage/layman.
I of course realize that change the structure of the whole portdir would
had inresting complications, so take this comment just as serious as you
like.

But overlays really was an afterthought?

Re: [gentoo-dev] Re: [rfc] layman storage location (again)

[Alex Alexander]

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

On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote:
> I sometimes think the main problem is the tree itself. Portage really
> should had a directory of its own, but maybe with anoher structure,
> like /var/portage, /var/portage/tree (the current
> PORTDIR), /var/portage/distfiles (i.e. split out distfiles from the tree
> itself), /var/portage/overlays/layman or /var/portage/layman.
> I of course realize that change the structure of the whole portdir would
> had inresting complications, so take this comment just as serious as you
> like.
> 
> But overlays really was an afterthought?

I like this suggestion, it certainly makes the whole folder structure
cleaner. If we're going to fix stuff, lets do it properly once and for
all.

Some compatibility code that checks and uses the old default locations
while printing out warnings would help existing users with the
transition without breaking current systems. Users with custom PORTDIR
and friends could be notified through a news item.

/var/portage/
/var/portage/tree
/var/portage/layman
/var/portage/overlays (non-layman managed, layman could also be in here)
/var/portage/distfiles
/var/portage/packages

or %s/var/usr/

-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com

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

Re: [gentoo-dev] Re: [rfc] layman storage location (again)

[Antoni Grzymala]

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

Alex Alexander dixit (2010-01-18, 11:07):

> On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote:
> > I sometimes think the main problem is the tree itself. Portage really
> > should had a directory of its own, but maybe with anoher structure,
> > like /var/portage, /var/portage/tree (the current
> > PORTDIR), /var/portage/distfiles (i.e. split out distfiles from the tree
> > itself), /var/portage/overlays/layman or /var/portage/layman.
> > I of course realize that change the structure of the whole portdir would
> > had inresting complications, so take this comment just as serious as you
> > like.
> > 
> > But overlays really was an afterthought?
> 
> I like this suggestion, it certainly makes the whole folder structure
> cleaner. If we're going to fix stuff, lets do it properly once and for
> all.
> 
> Some compatibility code that checks and uses the old default locations
> while printing out warnings would help existing users with the
> transition without breaking current systems. Users with custom PORTDIR
> and friends could be notified through a news item.
> 
> /var/portage/
> /var/portage/tree
> /var/portage/layman
> /var/portage/overlays (non-layman managed, layman could also be in here)
> /var/portage/distfiles
> /var/portage/packages
> 
> or %s/var/usr/

Very much +1.

-- 
[a]

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

Re: [gentoo-dev] Re: [rfc] layman storage location (again)

[Michael Haubenwallner]

Alex Alexander wrote:
> On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote:
>> I sometimes think the main problem is the tree itself. Portage really
>> should had a directory of its own, but maybe with anoher structure,
>> like /var/portage, /var/portage/tree (the current
>> PORTDIR), /var/portage/distfiles (i.e. split out distfiles from the tree
>> itself), /var/portage/overlays/layman or /var/portage/layman.
>> I of course realize that change the structure of the whole portdir would
>> had inresting complications, so take this comment just as serious as you
>> like.
<snip> 
> /var/portage/
> /var/portage/tree
> /var/portage/layman
> /var/portage/overlays (non-layman managed, layman could also be in here)
> /var/portage/distfiles
> /var/portage/packages

Not that I really care, but are these "portage-only" and we might need
/var/{paludis,pkgcore,...}/*? So what about /var/gentoo/*?

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

[gentoo-dev] Re: Re: [rfc] layman storage location (again)

[Peter Hjalmarsson]

mån 2010-01-18 klockan 12:40 +0100 skrev Michael Haubenwallner:
> Alex Alexander wrote:
> > On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote:
> >> I sometimes think the main problem is the tree itself. Portage really
> >> should had a directory of its own, but maybe with anoher structure,
> >> like /var/portage, /var/portage/tree (the current
> >> PORTDIR), /var/portage/distfiles (i.e. split out distfiles from the tree
> >> itself), /var/portage/overlays/layman or /var/portage/layman.
> >> I of course realize that change the structure of the whole portdir would
> >> had inresting complications, so take this comment just as serious as you
> >> like.
> <snip> 
> > /var/portage/
> > /var/portage/tree
> > /var/portage/layman
> > /var/portage/overlays (non-layman managed, layman could also be in here)
> > /var/portage/distfiles
> > /var/portage/packages
> 
> Not that I really care, but are these "portage-only" and we might need
> /var/{paludis,pkgcore,...}/*? So what about /var/gentoo/*?
> 
> /haubi/

I think "gentoo" is too non-specific. "portage" is more or less a good
name for everything with regards to the package management in gentoo.

That there is a name collision between that and the default
implementation of a package manager I see just as an coincidence.
Just like Gentoo both can refer to a distribution and a file-browser.
Or RPM is both a file-format and a tool to handle said file format.

Re: [gentoo-dev] [rfc] layman storage location (again)

[Sebastian Pipping]

On 01/18/10 01:38, Sebastian Pipping wrote:
> On 01/17/10 21:31, Thilo Bangert wrote:
>> /var/layman i dislike due to this sentence in the FHS:
>>
>>    "Applications must generally not add directories to the top level of 
>> /var. Such directories should only be added if they have some system-wide 
>> implication[...]"
> 
> [..]
> 
> current ranking through my eyes:
> 
> 1) /var/layman       con: adds folder to /var, maybe should not
> 2) /var/db/layman    con: you tell me
> 3) /var/lib/layman   con: not really /var/lib-style data

let me put the thoughts we collected so far to a decision.

looking at /var shows, that not many application really dared to have a
dedicated folder in /var directly:

  # find /var -maxdepth 1 -type d
  /var
  /var/tmp
  /var/lost+found
  /var/www
  /var/cache
  /var/spool
  /var/run
  /var/lock
  /var/db
  /var/gdm    <-- gnome-base/gdm
  /var/lib
  /var/empty  <-- net-misc/openssh
  /var/log
  /var/state

after re-considering the requirements for /var/lib/layman the data in
there can be host-specific (and therefore is not host-independent in
general).  i think it fits _well enough_ and to my impression it has
less potential of turning out wrong than non-FHS /var/db:

  so /var/lib/layman is the new default.

expect related commits to layman soon.



sebastian

Re: [gentoo-dev] [rfc] layman storage location (again)

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 237 bytes --]

On Monday 18 January 2010 19:05:23 Sebastian Pipping wrote:
>   /var/empty  <-- net-misc/openssh

this isnt exactly openssh specific.  a few other packages use it as well for 
their users because it's guaranteed to be empty.
-mike

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

Re: [gentoo-dev] [rfc] layman storage location (again)

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 966 bytes --]

On Sunday 17 January 2010 15:31:26 Thilo Bangert wrote:
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> said:
> > I realise this is a lost cause, but... Repositories are databases, so
> > /var/db/ is your friend.
> 
> i like it. Closely followed by /var/lib/layman...
> 
> wikipedia says in
> http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
> 
> /var/lib/
>   State information. Persistent data modified by programs as they run,
> e.g., databases, packaging system metadata, etc.
> 
> /var/layman i dislike due to this sentence in the FHS:
> 
>    "Applications must generally not add directories to the top level of
> /var. Such directories should only be added if they have some system-wide
> implication[...]"

while i think portage/layman should have their tree split up better, i dont 
think this particular argument applies considering portage (and any overlays 
it uses) absolutely has system-wide implications ...
-mike

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