Too many unowned directories

Panu Matilainen pmatilai at laiskiainen.org
Mon Feb 2 10:42:08 UTC 2009


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 -




More information about the devel mailing list