On Mon, 2 Feb 2009, Michael Schwendt wrote:
On Mon, 02 Feb 2009 09:35:37 +0100, Hans wrote:What about Panu's suggestion to just abort the install when trying to install a file in to a non-existing directory, instead of creating the dir on the fly.Confronting users with these packaging mistakes sounds very wrong to me. Does "aborting the install" here means that the RPM transaction check would catch these mistakes? That would be too late, it would break all those untested mass-dist-updates and create chaos - it would be a DoS situation for normal updates.
Yup, that'd be having rpm transaction check fail. And sure it's fairly draconian, but maybe it'd teach the packagers not to do untested mass-dist-updates after getting bombarded with bug reports a few times :P
If mock/koji did a test install of the freshly built package into the build chroot, that'd catch these and all sorts of other silly mistakes too (Ever made a typo in manual dependency, scriptlet or so, making the package uninstallable? I know I have...) without exposing the poor users to packagers mistakes.
Some packagers rewrite their %files section in spec files so often, they flip forth and back from owned dirs to unowned dirs, simply because %dir and recursive inclusion are not understood [yet]. There are even people on IRC who give wrong/misleading advice wrt dirs in %files sections, and newbie packagers listen to them.
Would it help just to have rpmbuild *report* unowned directories at build-time? That would of course give a great deal of false positives (you'd probably want to filter at least directories from the filesystem package out), but it would provide an easy way for a packager to eyeball for anything suspicious. Such as
Note: directories not explicitly owned by package libfoo: /usr/lib /usr/share/foo - Panu -