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