Dne 16.8.2012 14:46, Ralf Corsepius napsal(a):
On 08/16/2012 02:29 PM, Miroslav Suchy wrote:
Hi,
I packaged dozen of packages and I'm used to put LICENSE and README
files just as:
%doc README LICENSE
which place these files in:
/usr/share/doc/%{name}-%{version}
Recently I started packaging some rubygems and reviewers pointed [1,2]
me that I should not explicitly move these files to this location and
leave them in %{gem_instdir}.
I do not feel it is correct behaviour.
Agreed.
Though there can be reasons for not putting LICENSE and README files
into %_docdir [1], I am inclined to believe the ruby packages's
behavior to be a "bad habit" which ought to be abandoned.
You should distinguish between Ruby packages and RubyGems packages,
where Mirek actually refers to the later. Although this might be small
difference to you, the reality is, that each RubyGem package reside in
exactly one path, where Ruby package files goes to one shared directory
with no strict naming conventions. So if you keep README from RubyGem
package in the original location, they do not conflict, while if you
would do the same for Ruby packages, there could be conflicts. So for
Ruby packages, it makes sense to put them into /usr/share/doc while for
RubyGems packages, it makes sense to keep the gem structure as close to
the original gem as possible.
And there are other reasons why not move the documentation around:
* For every Ruby package, you can generate its documentation using RDoc.
If you keep the license in the original place, the generated
documentation will cover it, if you move it somewhere else, it will be
missing from documentation.
* Metadata of the gem may refer to the documentation files. However I do
not expect any issues in this area.
* Sometimes happens, that there is VERSION file which is referenced by
code, which might cause broken behavior or library.
* It is more work.
Vit
Ralf
[1] Eg. READMEs may document files neighboring them. Forcing such
READMEs into %_docdir doesn't make much sense, IMO.
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
