Michael Schwendt wrote:
On Sun, 15 Feb 2009 10:59:30 -0800, Toshio wrote:
>> How about:
>> In a Fedora package .spec file, any of the files/dirs installed in
>> the buildroot must not be included in the package(s) %files lists more
>> than once. Unless there is good reason, and in that case there ought to
>> be a comment in the .spec file.
> What's an example of a good reason?
A comment in the spec files which explains _why_ the files are duplicated. ;-)
I mean, what are examples when packagers should include files or
directories in two %files sections for separate subpackages.
> (For instance, I want to know if including README/COPYING in
> subpackages is best practice or should be frowned upon).
Can you point to a package that does that?
Perhaps examining specific pkgs would help?
Nope. Villa said this would be a reason that packagers would have to
resort to a separate subpackage for the docs. I'm sort of questioning
whether this ever comes up in practice.
If it shall be possible to install the subpackages individually and
separate from eachother, that may be reason enough to include such %doc
files in each pkg as a matter of convenience for the user [and as not to
create a -common pkg for just a few files]. Same applies to directories,
as not to create a -common pkg just for directory ownership. In general,
it may even be applicable to scripts and binaries shared by separately
Do we have examples of where this is a problem? Most subpackages would
depend on their main package and that package could create the
directories needed by the independent parts. I understand the theory
here but I'd like to see some examples of where this is a real-life
problem so we can point people at it.
This has gone from a clarification of wording to downgrading a MUST to a
SHOULD. I'd like to understand what problems we're solving by doing
that so we can write better Guidance of when it's appropriate and not
appropriate to duplicate files in different sections. 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.
If it's a lib pkg that includes the docs a 2nd time in the -devel
that would be bad. In particular because usually the -devel pkg requires
the main lib pkg -- and because our placement of %doc files is broken.
Every subpackage creates its own docdir, which means that a lib and its
-devel pkg put their %doc files into two docdirs.
Or not a good reason would be if a packager duplicates files in subpkgs
just to make rpmlint ("No documentation") happy.
Yep, agreed on both counts that a package that does this should be
corrected instead of being commented and passed through review.