1 |
On Sat, 11 Nov 2017 12:31:15 -0500 |
2 |
Michael Orlitzky <mjo@g.o> wrote: |
3 |
|
4 |
|
5 |
> Essentially,we have two commands to create a directory, "dodir" and |
6 |
> "do-empty-dir" (which we call "keepdir"). The latter is only necessary |
7 |
> due to an implementation detail, so it doesn't belong in the user |
8 |
> interface -- the PM should figure out what to do. |
9 |
> |
10 |
> As far as the actual implementation goes, I'm not sure that |
11 |
> automatically-generated ".keep" files are better than having the |
12 |
> package manager maintain its own database. The latter would be more |
13 |
> complex, but would avoid littering everyone's filesystems with |
14 |
> ".keep" files. |
15 |
> |
16 |
|
17 |
Well, for: |
18 |
|
19 |
1) using .keepdir files makes this package manager non-specific, ie: |
20 |
using a different PM would mean it too sees that it is suppose to be |
21 |
kept. |
22 |
|
23 |
2) Most ebuilds don't need/or use .keepdir, so I doubt there are that |
24 |
many littering up your filesystem. |
25 |
|
26 |
3) There already is a database of the files installed by a package. |
27 |
But, how does it know which other packages might need to install to |
28 |
that directory. So, what does it do on unmerge of the package. |
29 |
Typically, the package manager will refuse to remove a non-empty |
30 |
directory after the files it is removing are removed. |
31 |
|
32 |
4) Creating a single database for these will make the system more |
33 |
vulnerable to corruption and data loss. It would save on disk usage |
34 |
and number of inodes used. But there is a tradeoff between space and |
35 |
robustness. If one .keepdir is lost, it may only affect a few |
36 |
packages. If the database becomes corrupted. It could potentially |
37 |
mean the loss of much more of your installed pkg data. Spanning a |
38 |
great deal of the installed pkgs. In this case simplicity |
39 |
of .keepdir is in my opinion, much better than a single db. |
40 |
|
41 |
-- |
42 |
Brian Dolbec <dolsen> |