+1 to the proposal in general. If you go the macro path, be sure to catch README and LICENSE files that have extensions, such as .md or .adoc.
-Dan On Aug 29, 2013 6:13 AM, "Vít Ondruch" <[email protected]> wrote: > Dne 29.8.2013 11:13, Miroslav Suchý napsal(a): > >> Hi, >> all rubygems put their README and LICENSE files in %{gem_instdir}. This >> is opposed to all other packages, which put such files into >> %{_docdir}/%{name}-%{version}. And all users and developers expect those >> files in this directory. Of course but ruby developers who expect them in >> %{gem_instdir}. >> >> Therefore I propose to put into Ruby guidelines this scriplet to unify >> this behavior: >> >> ``` >> %install >> mkdir -p %{buildroot}%{_pkgdocdir} >> for docfile in README; do >> mv %{buildroot}%{gem_instdir}/$**docfile %{buildroot}%{_pkgdocdir} >> ln -s %{_pkgdocdir}/$docfile %{buildroot}%{gem_instdir} >> done >> >> %files >> %doc %{gem_instdir}/README >> %doc %{_pkgdocdir}/README >> ``` >> >> and put this text into ruby guidelines: >> ``` >> All documentation files, which resides in %{gem_instdir}, should be moved >> to %{_pkgdocdir}. Symbolic link from %{gem_instdir}/<moved file> to >> %{_pkgdocdir}/<moved file> should be created. This especially apply on >> README and LICENSE files. >> ``` >> >> Obviously the choice is to have symlink from %{gem_instdir} to >> %{_pkgdocdir}. Or from %{_pkgdocdir} to %{gem_instdir}. >> I choosed the first option as those doc files are not needed for runtime >> and IMO should not be located in %{gem_instdir} and it should be located >> under /usr/share/doc as all other packages do. >> >> Opinions? >> >> > If you proposing such changes, you should finish your mental exercise and > propose something like %gem_doc or whatever would be the name of the macro > and the usage would be simple as: > > %files > %gem_doc README > > Even the %doc macro could be made smarter, so it would install the files > on appropriate places simple as: > > %files > %doc README > > However, I am not sure how feasible are these two ideas. > > Vít > ______________________________**_________________ > ruby-sig mailing list > [email protected].**org <[email protected]> > https://admin.fedoraproject.**org/mailman/listinfo/ruby-sig<https://admin.fedoraproject.org/mailman/listinfo/ruby-sig>
_______________________________________________ ruby-sig mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
