1 |
On Wed, Jul 18, 2018 at 9:30 AM Ulrich Mueller <ulm@g.o> wrote: |
2 |
> |
3 |
> >>>>> On Wed, 18 Jul 2018, Rich Freeman wrote: |
4 |
> |
5 |
> > On Wed, Jul 18, 2018 at 5:55 AM Ulrich Mueller <ulm@g.o> wrote: |
6 |
> >> Also, there is that strange requirement that the |
7 |
> >> file hierarchy must not be exposed to users. At least for the |
8 |
> >> make.profile link we rely on a well defined hierarchy, and certainly |
9 |
> >> expose it to users. |
10 |
> |
11 |
> > That isn't true at all. When you run eselect profile you have no idea |
12 |
> > what it is looking at. |
13 |
> |
14 |
> If I run eselect profile, it shows a list of pathnames like |
15 |
> default/linux/amd64/17.1/desktop. If that doesn't expose the "specific |
16 |
> file hierarchy" then I wonder what could ever qualify? |
17 |
|
18 |
It lists profile names. The fact that our profiles are implemented |
19 |
using paths is an implementation detail. And you would have no idea |
20 |
that they're stored in /usr or /var from the output of eselect. If we |
21 |
modified PMS so that profiles were stored in a mysql database the |
22 |
current eselect output could work just fine. |
23 |
|
24 |
> Also eselect profile is a tool for convenience only, and nobody is |
25 |
> forced to use it. The make.profile symlink and its target are |
26 |
> mentioned in our documentation and users can set it manually. |
27 |
|
28 |
So is /var/lib/portage/world. Are you planning to move that to /etc? |
29 |
(I wouldn't object to that, actually.) |
30 |
|
31 |
Personally I think that a lot of this comes from the standpoint of a |
32 |
typical distro where command lines are things that should be hidden as |
33 |
deeply in the gnome menus as possible. But, my point is that if you |
34 |
want that kind of experience on Gentoo it is certainly possible |
35 |
insofar as profiles are concerned. |
36 |
|
37 |
> Hopefully we will keep having such users who want to understand the |
38 |
> inner workings, instead of being satisfied with a black box. :) |
39 |
> Ebuild repositories are human readable text, and we shouldn't move |
40 |
> them to a hidden location. |
41 |
|
42 |
There is nothing hidden about /var/lib. And I also prefer editing |
43 |
text files for the most part. My point is that FHS wasn't really |
44 |
written with Gentoo as its main target, and that is likely the reason |
45 |
for the bit about hiding paths. |
46 |
|
47 |
> |
48 |
> >> The same is true for license information in |
49 |
> >> /usr/portage/licenses. |
50 |
> |
51 |
> > You have a fair point there. Honestly, I don't really see this as a |
52 |
> > good reason on its own to abandon /var/lib, which is where other |
53 |
> > distros seem to stick stuff like this. Also, you don't need to poke |
54 |
> > around that directory to determine what license a package uses - just |
55 |
> > to read the text of the license itself (which could arguably just be |
56 |
> > stored on our webserver unless we're actually redistributing something |
57 |
> > in the repository under that license, which is unlikely in general |
58 |
> > since patches/etc are probably fair use). |
59 |
> |
60 |
> I totally disagree here. We keep local copies of licenses for good |
61 |
> reasons, and storing them on our webserver is no substitute. |
62 |
|
63 |
I'm not sure what you're disagreeing with. I'm not advocating for not |
64 |
storing them locally. I'm just saying it could be done, and I did say |
65 |
that you had a fair point. |
66 |
|
67 |
> No, the argument is that we already use /var/db/pkg, and grouping |
68 |
> other related things with it seems natural. |
69 |
|
70 |
Perhaps we should be trying to move away from using /var/db, and not |
71 |
doubling down? |
72 |
|
73 |
> Apart from this (quoting the devmanual): "Gentoo does not consider |
74 |
> the Filesystem Hierarchy Standard to be an authoritative standard, |
75 |
> although much of our policy coincides with it." And the discussion so |
76 |
> far has shown that the FHS wasn't designed for our use case. We can |
77 |
> still use it as a guideline, but maybe we shouldn't jump through |
78 |
> hoops, only to make it completely fit. |
79 |
|
80 |
Sure, I'd agree with that, but why not use /var/lib then? Your only |
81 |
argument against it is based on the FHS, which you freely concede |
82 |
wasn't written to fit our use case. |
83 |
|
84 |
> The only thing that seems certain is that regardless of what we will |
85 |
> do, we cannot make everybody happy. We shouldn't take that as an |
86 |
> excuse to do nothing, because /usr/portage is no good solution either. |
87 |
|
88 |
Well, the one thing I like about all these proposals is that it will |
89 |
result in Gentoo systems with a wide mixture of locations for these |
90 |
things, which will guarantee that any script that hard-codes paths |
91 |
will break. That means that those who exercise their choice to do |
92 |
things in a more sane way than our defaults will probably run into |
93 |
less trouble... |
94 |
|
95 |
-- |
96 |
Rich |