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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
