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