From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 3DE7B138334 for ; Fri, 13 Jul 2018 19:33:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2CE68E0825; Fri, 13 Jul 2018 19:33:57 +0000 (UTC) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A46FCE0823 for ; Fri, 13 Jul 2018 19:33:56 +0000 (UTC) Received: by mail-ed1-x532.google.com with SMTP id v22-v6so25389904edq.4 for ; Fri, 13 Jul 2018 12:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scriptkitty-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=qC2s9AmHp7qean+BoQ/qWmzNyXQpK7ci8nv4ltESZIM=; b=IHEtcSExquf43I0wn7380zP4WexB63bHuu3R8fZ+HdGo5Vtkx6zHjC8Hm/Fui031J9 NCapseNQmOGcsSzg2yx/MjHLHwWpgmWrP/Lj5laGVUKvXCfp37BUkH/E9POlt3rGf60L C2SXF99M5qOTW1BTwOtm2jsxLoj1j8O0pfQvzv1OWmbVemgOuA/GjuVrhZuc8WNE8pAi XXWZLsPHDelDCJM8cbv3KO/nQN+OYa0NTOMNMv8t0+It8CN5go4Cd/9oXgpugqgaHEyz KpMdTW+j/Kq+WkmkbJeY0MgXyWekQWSdHex0XIz5zJ/lloifjHXrR+AeBYwnDgOxPoQQ XPMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=qC2s9AmHp7qean+BoQ/qWmzNyXQpK7ci8nv4ltESZIM=; b=r375U6ba/mGqxGNTq3PBESewdbE5Ik+bsNaF7W6emi+NiEqrruXHv0FieBgxhJeWBV zzFA60o+tkSV5M7TijDTtF4yIe73a0PU+/L062s4/6ZcnVNRTF3St/w8zV2eTvFVikyQ loFh3famwkOewCyKnQhcS3FhYrfyIEl5EczCpZxkMp+RGK8gALHh0xSXlZh3BAS8h/ig 2GzcMuYYofGb5bYwVlOp3lq2GxGkoqLCXohU0ONqzIWJP25Ng3TmexH+C/BF7tzxzxdD g34r3FdTAdCI4Bl7hKI0eCayFkAkGJTzwOd9Ckj+fEo4BmXOyUAx0mFRm/KXixUlqU1N IkdA== X-Gm-Message-State: AOUpUlERJnbiLy2NUUa63+bnFaScynk1TKAHgfKXtJ0y9HG9NV7ROXZb JRANj+YxENXJCXpXtKcf0/usn6wZggyOn32UD8Ax27Oz0JY= X-Google-Smtp-Source: AAOMgpelVcohkuYDtBOvktz6tVTFOkl8YJoSw98EWdHmjNVZcziZuJPsc6mIKcdha3QzOImcF80hWnwtARurGE+HSoM= X-Received: by 2002:a50:d617:: with SMTP id x23-v6mr8569122edi.178.1531510434819; Fri, 13 Jul 2018 12:33:54 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 Sender: antarus@scriptkitty.com Received: by 2002:a17:906:d0c4:0:0:0:0 with HTTP; Fri, 13 Jul 2018 12:33:54 -0700 (PDT) X-Originating-IP: [2620:0:1003:510:44a8:eae2:2743:2dcb] In-Reply-To: <23368.64354.849449.669215@a1i15.kph.uni-mainz.de> References: <23368.25818.481969.336756@a1i15.kph.uni-mainz.de> <20180713065734.63627e6f@professor-x> <23368.58952.48436.482420@a1i15.kph.uni-mainz.de> <23368.64354.849449.669215@a1i15.kph.uni-mainz.de> From: Alec Warner Date: Fri, 13 Jul 2018 15:33:54 -0400 X-Google-Sender-Auth: aa__Q9c8fWs8_fl7LAbdPozKI60 Message-ID: Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2018-07-29 To: gentoo-project Content-Type: multipart/alternative; boundary="0000000000007007340570e68fab" X-Archives-Salt: 1ad2340d-9d8b-4632-a8a5-d7dbf344449a X-Archives-Hash: d5f28413d53f68f92e1658f125b86583 --0000000000007007340570e68fab Content-Type: text/plain; charset="UTF-8" On Fri, Jul 13, 2018 at 3:20 PM, Ulrich Mueller wrote: > >>>>> On Fri, 13 Jul 2018, Rich Freeman wrote: > > > I'd suggest refactoring this a bit. We have a couple of directories. > > We need to establish the base, and then the directory name under that. > > > We have: > > distfiles > > packages > > main repo > > overlays > > > These can go under: > > /var/db > > /var/cache > > /var/lib > > > You have just about every sane permutation of these as options, so I > > suggest considering the two separately. > > > I think the pros/cons of the second question have already been hashed > > out. I tend to agree with the /var/lib arguments for all but > > distfiles (FHS directly gives the example of browser cache in > > /var/cache, and that is very much what distfiles is). > > Agreed, so far. > > > For the directory under each I suggest a gentoo/portage parent > > directory, and then a tree underneath: > > .../gentoo/repos/gentoo (this is PMS) > > .../gentoo/repos/myoverlay (this is PMS) > > .../gentoo/packages (I'm not sure if this is PMS - move to portage if > not) > > .../gentoo/distfiles (I don't think this is PMS, but it is so > > generic that it probably should be considered shared) > > Why the "gentoo" path component? That's not a package, and therefore > not compliant with the FHS. (Or even worse, it actually _is_ a > package, namely app-misc/gentoo.) > > > .../portage/edb (I think this is portage-specific) > > .../portage/pkg (I think this is also portage-specific) > > > Stuff that is specific to portage and not specified in PMS would go in > > .../portage. Stuff that is PMS-specified would go in .../gentoo. > > > Note that not all these directories need be under the same base. We > > could have /var/lib/gentoo/repos, and /var/cache/gentoo/distfiles. > > So, the base needs to be decided for each. > > > Finally, my list of final recommendations given this framework: > > > /var/lib/gentoo/repos/gentoo (I'm fine with cache here as well) > > Here we're at 5 path components again. I will likely vote against any > proposal that would put the tree such deep in the hierarchy. And the > double "gentoo" adds some extra ugliness. > > > /var/cache/gentoo/packages (These are package builds and are > > completely reproducible.) > > /var/cache/gentoo/distfiles (This is literally a network > cache/mirror) > > /var/cache/portage/edb (This is portage-specific, > > but it can be regenerated) > > /var/lib/portage/pkg (This is the must-preserve > > metadata state of the system, in portage's internal format.) > > Why not keep this at /var/db/pkg? That's the path mentioned in PMS. > +1 to this. We know through experience that moving PORTDIR and DISTDIR are safe operations because a number of existing users point them at different locations and successfully use Gentoo. I want to avoid two things: - Being FHS compatible at any cost[0]. This is IMHO, not an explicit goal. We are FHS compatible when its convenient to be, and we are incompatible when its expensive to fix or change. - Tying easy changes with hard changes. Let not the perfect be the enemy of the good! We can still move distdir and portdir (low cost, easy!) and decide to make other changes later. I want to avoid the case where we decide that "moving /var/db/pkg is hard, so in conclusion we will do nothing." That is not a useful conclusion and there is no reason why these changes must be made together[1]. [0] If this were literally the only non-FHS compatible thing we had left, then I'd find that argument more compelling that we should change it to be 100% compatible. I remain unconvinced that this is the case today, and unconvinced that being FHS compatible gains us anything useful. I'd love to hear more about this though. [1] Incremental change is the only real change. -- a proverb. -A > > > /var/lib/portage/world (Current state - at least > > something is already in the right place...) > > Ulrich > --0000000000007007340570e68fab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 13, 2018 at 3:20 PM, Ulrich Mueller <<= a href=3D"mailto:ulm@gentoo.org" target=3D"_blank">ulm@gentoo.org> wrote:
>>>= ;>> On Fri, 13 Jul 2018, Rich Freeman wrote:

> I'd suggest refactoring this a bit.=C2=A0 We have a couple of dire= ctories.
> We need to establish the base, and then the directory name under that.=

> We have:
> distfiles
> packages
> main repo
> overlays

> These can go under:
> /var/db
> /var/cache
> /var/lib

> You have just about every sane permutation of these as options, so I > suggest considering the two separately.

> I think the pros/cons of the second question have already been hashed<= br> > out.=C2=A0 I tend to agree with the /var/lib arguments for all but
> distfiles (FHS directly gives the example of browser cache in
> /var/cache, and that is very much what distfiles is).

Agreed, so far.

> For the directory under each I suggest a gentoo/portage parent
> directory, and then a tree underneath:
> .../gentoo/repos/gentoo=C2=A0 =C2=A0 (this is PMS)
> .../gentoo/repos/myoverlay (this is PMS)
> .../gentoo/packages=C2=A0 =C2=A0(I'm not sure if this is PMS - mov= e to portage if not)
> .../gentoo/distfiles=C2=A0 =C2=A0 =C2=A0 (I don't think this is PM= S, but it is so
> generic that it probably should be considered shared)

Why the "gentoo" path component? That's not a package,= and therefore
not compliant with the FHS. (Or even worse, it actually _is_ a
package, namely app-misc/gentoo.)

> .../portage/edb=C2=A0 =C2=A0 =C2=A0(I think this is portage-specific)<= br> > .../portage/pkg=C2=A0 =C2=A0 =C2=A0 (I think this is also portage-spec= ific)

> Stuff that is specific to portage and not specified in PMS would go in=
> .../portage.=C2=A0 Stuff that is PMS-specified would go in .../gentoo.=

> Note that not all these directories need be under the same base.=C2=A0= We
> could have /var/lib/gentoo/repos, and /var/cache/gentoo/distfiles.
> So, the base needs to be decided for each.

> Finally, my list of final recommendations given this framework:

> /var/lib/gentoo/repos/gentoo=C2=A0 =C2=A0 =C2=A0 =C2=A0 (I'm fine = with cache here as well)

Here we're at 5 path components again. I will likely vote agains= t any
proposal that would put the tree such deep in the hierarchy. And the
double "gentoo" adds some extra ugliness.

> /var/cache/gentoo/packages=C2=A0 =C2=A0 =C2=A0 =C2=A0 (These are packa= ge builds and are
> completely reproducible.)
> /var/cache/gentoo/distfiles=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(T= his is literally a network cache/mirror)
> /var/cache/portage/edb=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 (This is portage-specific,
> but it can be regenerated)
> /var/lib/portage/pkg=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(This is the must-preserve
> metadata state of the system, in portage's internal format.)

Why not keep this at /var/db/pkg? That's the path mentioned in P= MS.

+1 to this.

We know through experience that moving PORTDIR and DISTDIR are safe opera= tions because a number of existing users point them at different locations<= /div>
and successfully use Gentoo. I want to avoid two things:

=C2=A0- Being FHS compatible at any cost[0]. This is IMHO,= not an explicit goal. We are FHS compatible when its convenient to be, and= we are incompatible when its expensive to fix or change.
=C2=A0-= Tying easy changes with hard changes. Let not the perfect be the enemy of = the good! We can still move distdir and portdir (low cost, easy!) and decid= e to make other changes later. I want to avoid the case where we decide tha= t "moving /var/db/pkg is hard, so in conclusion we will do nothing.&qu= ot; That is not a useful conclusion and there is no reason why these change= s must be made together[1].

[0] If this w= ere literally the only non-FHS compatible thing we had left, then I'd f= ind that argument more compelling that we should change it to be 100% compa= tible. I remain unconvinced that this is the case today, and unconvinced th= at being FHS compatible gains us anything useful. I'd love to hear more= about this though.
[1] Incremental change is the only real chang= e. -- a proverb.

-A
=C2=A0

> /var/lib/portage/world=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0(Current state - at least
> something is already in the right place...)

Ulrich

--0000000000007007340570e68fab--