| Summary: | "keepir" specification too precise, and (un)merging missing | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | TGL <tom.gl> |
| Component: | PMS/EAPI | Assignee: | Package Manager Specification <pms> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
r141 allows for .keep* as the name. I'm skeptical about loosening up the wording to allow non-empty-based directory ownership logic... I suspect that implementing things any other way would lead to too much confusion. Marking this as fixed ... if the merging logic becomes an issue it can be reopened. |
PMS draft from 2007/03/25 says about "keepdir": Creates a directory as for dodir, and an empty .keep ο¬le in it to ensure that the directory does not get removed by the package manager should it be empty at any point. I think this description is either too much or not enough (or both): 1/ too much because there are many ways to prevent empty dirs' unmerging. For instance, Portage no more uses ".keep" files afaik, but rather ".keep_${CATEGORY}_${PN}-${SLOT}" (much safer in case several packages keep a same directory). One could also imagine a PM which would maintain some "files and dir -> owning package" database, and thus would not need this kind of trick, etc. I think something less precise, like this, would be enough: * dodir: [...] If the package leaves this directories empty, there is no guarantee that they will actually be installed. * keepir: Similar to dodir, but with the guarantee that empty dirs will actually be installed. 2/ not enough because this paragraph alone, without a specification of the merging and unmerging algorithms, and how package upgrades are done (merge the new instance first, and then unmerge the old one), doesn't really makes sense imho. Maybe i'm wrong, but i have the feeling that i've only understood what it was about only because i know more about the behavior of my PM than what PMS explicitly says/requires. Actually, I think a specification of merging and unmerging behaviors is really necessary in PMS for many other reasons. For instance, is it okay or not to have in a tree both: - pkgA which installs a "/foo/bar" directory - pkgB which installs in "/foo" a "bar" symlink to dir "baz" That's things which have an impact on what "legal" ebuilds are (or what "compliant" packager managers are, depending on your pov).