| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 03/28/2012 02:53 PM, Christoph Mende wrote: |
| 5 |
> On Wed, Mar 28, 2012 at 8:43 PM, Aaron W. Swenson |
| 6 |
> <titanofold@g.o> wrote: |
| 7 |
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 |
| 8 |
>> |
| 9 |
>> On 03/27/2012 03:05 PM, William Hubbs wrote: |
| 10 |
>>> All, |
| 11 |
>>> |
| 12 |
>>> I know this has come up before, but I don't really recall what |
| 13 |
>>> the specific objections were. |
| 14 |
>>> |
| 15 |
>>> IMO the portage directory doesn't belong under /usr at all. I |
| 16 |
>>> was chatting with another developer who uses |
| 17 |
>>> /var/cache/portage/{tree,distfiles}, and I'm thinking about |
| 18 |
>>> switching my default setup to do this. |
| 19 |
>>> |
| 20 |
>>> I realize that historically the portage tree has been |
| 21 |
>>> installed under /usr, but Can we consider changing this default |
| 22 |
>>> for new installations and providing instructions for users for |
| 23 |
>>> how to get the portage tree out of /usr? William |
| 24 |
>>> |
| 25 |
>> |
| 26 |
>> So, we're all getting way off topic and discussing reorganizing |
| 27 |
>> the whole enchilada. |
| 28 |
>> |
| 29 |
>> How about we all agree or disagree on the primary point: The |
| 30 |
>> Portage tree doesn't belong in /usr. |
| 31 |
>> |
| 32 |
>> I believe that it does belong under /var/cache/. |
| 33 |
> |
| 34 |
> I believe it's /var/lib/<name>. Here's what FHS says: /var/cache is |
| 35 |
> intended for cached data from applications. Such data is locally |
| 36 |
> generated as a result of time-consuming I/O or calculation. The |
| 37 |
> application must be able to regenerate or restore the data. Unlike |
| 38 |
> /var/spool, the cached files can be deleted without data loss. |
| 39 |
> |
| 40 |
> And: /var/lib/<name> is the location that must be used for all |
| 41 |
> distribution packaging support. |
| 42 |
> |
| 43 |
|
| 44 |
'Support' is the keyword here. The repositories are regenerated given |
| 45 |
machinesan 'emerge --sync' and can be considered as temporary as the |
| 46 |
packages themselves are impermanent. Further, the repository isn't |
| 47 |
required to persist. If somebody really wanted to be hard on our |
| 48 |
infrastructure, they could do an 'emerge --sync' at boot to repopulate |
| 49 |
/var/cache/gentoo-repos/. |
| 50 |
|
| 51 |
Portage PMS already does the right thing and uses /var/lib/ for the |
| 52 |
appropriate use, config and world, things that need to persist between |
| 53 |
reboots. |
| 54 |
-----BEGIN PGP SIGNATURE----- |
| 55 |
Version: GnuPG v2.0.17 (GNU/Linux) |
| 56 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
| 57 |
|
| 58 |
iF4EAREIAAYFAk9zZKMACgkQVxOqA9G7/aCcUAD+JEnR5dE1S7QNUr+8zNFzh/kR |
| 59 |
hlnZUXopuQSrMhxjxYEA/AlT2I5p4KEiGybgDELTnVNqOHNKlpO5RepBMjhII1Yy |
| 60 |
=sjCv |
| 61 |
-----END PGP SIGNATURE----- |
Archives