[Fedora-packaging] Guidelines#DuplicateFiles clarification

Michael Schwendt mschwendt at gmail.com
Mon Feb 16 09:08:57 UTC 2009


On Sun, 15 Feb 2009 13:55:09 -0800, Toshio wrote:

> I mean, what are examples when packagers should include files or
> directories in two %files sections for separate subpackages.

No -common pkg, no shared main pkg, but multiple subpackages which may be
installed independently. Imagine plugin pkgs: one for MySQL, another one
for Postgresql, even another one for SQLite ... you may want to put %doc
files into each subpkg.

One can expand that line of thinking and also duplicate directories and
other types of files in each subpkg -- and consider a common pkg only if
the gain would be big enough.

Whether packages SHOULD duplicate files/dirs or MAY do it, is another
question. According to the current guideline it MUST NOT be done.

Concerning %doc license texts, the ReviewGuidelines are not clear enough
with regard to subpkgs.

> This has gone from a clarification of wording to downgrading a MUST to a
> SHOULD. 

Sure. A guideline that is not understood cannot really be mandatory,
unless we follow such guidelines blindly nowadays. Hence we're reviewing
this guideline, and if nobody raises a hand and gives an explanation, it's
better to modify the guideline until examples are shown.

> Otherwise people
> who just want to check off review items aren't going to understand when
> it's sufficient to merely comment something out of the ordinary and when
> the out-of-the-ordinary should be changed.

How do they process this review item currently?

IMO, they simply tick off the item like an annoying checkbox without
really performing any tests related to "rpmls/rpm -qlvp". Or they only
watch for rpmbuild's lame warnings. Unowned directories and entire trees
(not just below %datadir) included in multiple subpkgs are evidence of
that.

With my reduced reviewing activity, I still run into packagers, who are
not familiar with their %files lists or who run into packaging pitfalls
related to %files lists.




More information about the Fedora-packaging mailing list