On Feb 23, 2008, at 6:49 AM, devzero2000 wrote:

Pardon, I have been too much synthetic: english is't my first language.

Then,I do not share the patch proposed in stable branch (rpm 4.4.6 and 5). The motivations are the same ones expressed in several mail on the argument in the past years, and I believe in the same reasons.

In particular, to my opinion, to impose in categorical way that the produced RPM do not depend on directory orphaned would obtain the same ones overal benefits in term of RPM QA that it has had "fascist check" in phase of build, almost for me: ok, is not a corrected comparison, but it renders the idea. Moreover, the system manegiability would be better if all the system components are expressed as package dependency.


Moreover the problem, from what I know, is famous from years, leading to the production of instruments as http://enrico-scholz.de/rpmDirectoryCheck/INFO : but i think that it is better that the problem is solved by rpm itself,

I hope of having express better my thought, Wrong that is, on the argument.


Thank you for clarifying your opinion.

I personally am still unsure whether having files depend on their parent directory (and symlinks depend on their end-point) was the right thing to do in rpm or not.

On the positive side, files depending on their parent directory will eventually succeed in establishing "ownership" of directories by a package, a worthy goal pointed out by Enrico years ago with rpmDirectoryCheck. Operations tied to creating a directory path, like setting selinux file contexts, are also more predictable and reliable if directories are handled explicitly as part of package installs. Managing unowned or pre-exsiting directories requires some guessing what the intended rwx
mode should be.

On the negative side, adding dependencies on parent directories adds some additional modest overhead to dependency solving. The fundamental conceptual issue is that parent directory dependencies are not explicitly included in package metadata as other dependencies are represented. This is surprising and mysterious implementation peculier
behavior for many users and applications and distros.

73 de Jeff

Reply via email to