Too many unowned directories

Michael Schwendt mschwendt at gmail.com
Mon Feb 2 09:08:01 UTC 2009


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.

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.

> This will not catch all cases, but will catch a lot, and is really easy to 
> implement (I think).
> 
> We could even complement this by also refusing to remove a package if *owned* 
> files are still left in a dir which it owns (and no other packages own). Then 
> we catch all error cases AFAIK.

In hope that those people, who would be burnt by such a refusal to remove
a pkg, will report all such problems instead of working around them.

No, the problem is not worse enough anymore, since RPM at least uses a
proper umask since F9. Since then it has become more interesting to
examine unowned dirs which are caused by other packaging mistakes (such
as misplaced files, missing sub-pkg deps).

> This means people will still need to manually get directory ownership right, 
> but if their just build rpm fails to install they will learn soon enough!

The script I'm using to detect unowned dirs in repos is released since
middle/autumn of last year
( http://mschwendt.fedorapeople.org/dircheck-remote.py ).
It has become really easy to check packages in Rawhide.

$ ./dircheck-remote.py -r rawhide -n bit-devel
=> bit-0.4.90-3.fc11.src.rpm
=> bit-devel-0.4.90-3.fc11.i386 (rawhide-development-i386)
/usr/include/bit-0.4

and it can be none or multiple -n options that each accept a regexp, so
it's easy to check all -devel pkgs, for example.




More information about the devel mailing list