On 09/03/14 09:25, Baptiste Daroussin wrote: > Hi all, > > On of the most borring thing IMHO in the plist maintainance is all the > directories. > > I have been working on some evolutions I want to share and discuss before > making > them official. > > First you have to know that since pkg 1.3 @dirrm and @dirrmtry are equivalent. > > Evolutions: > 1/ stop prepending directories in plist with @dir*: let pkg discover the path > correspond to a directory and handle it as such (easy)
Presumably if you need an empty directory, just add it to the plist.
> 2/ make pkg automatically remove directories under PREFIX without the need of
> adding them in plist, such as only empty directories and directories not under
> PREFIX will have to be listed. Of course pkg will not try to remove
> directories
> owned by another package.
There should be some concept of shared use directories, so eg. if
package foo installs /usr/local/foobar/foo and then later package bar
installs /usr/local/foobar/bar. Should you then delete package foo,
package bar should inherit ownership of /usr/local/foobar/
For a real example of this consider eg. p5-DBD-Pg and p5-DBD-Sqlite.
Probably we can just say directory /usr/local/foobar belongs to both
packages foo and bar, and it only gets deleted when the last owner is
removed and if it is empty.
Needs more thought though. What happens if two packages disagree about
ownership and permissions on a common directory? I guess that should
just be treated like a conflicting file, and block installation of the
second package.
> To achieve the point 2 that will mean we will stop using the mtree inside
> packages and create a "hier" package that will have the default hierarchy and
> every package but pkg will depend on this hier package (except if PREFIX !=
> LOCALBASE)
And if you follow the shared ownership idea to its logical conclusion,
/usr/local/bin, /usr/local/man and /usr/local/share end up with shared
ownership by almost every package you have installed. Would you
actually need to have a hier package at all? Although having one would
still be a good idea IMHO.
> 2 bonus of this approach:
> - it will speed up pkg operation by avoiding to have to extract the mtree for
> each package installation
> - it will simplify a lot check-plist
>
> Any opinion here?
Having both mtree and the package manifest both providing very similar
functionality is somewhat redundant.
Cheers,
Matthew
signature.asc
Description: OpenPGP digital signature
