[libvirt] [PATCH] spec: Only distribute ChangeLog in -devel package

Cole Robinson crobinso at redhat.com
Wed Sep 25 17:18:08 UTC 2013


On 09/04/2013 11:18 AM, Eric Blake wrote:
> On 09/04/2013 09:11 AM, Daniel P. Berrange wrote:
> 
>>> client: COPYING COPYING.LESSER
>>> daemon: none
>>> other[*]: AUTHORS ChangeLog.gz NEWS README TODO
>>>
>>> where I have yet another question: should the other package be
>>> libvirt-docs or libvirt-devel?  Your patch put them in devel, but I
>>> think docs might be a better fit.
>>
>> Oh, I didn't realize we had a -docs package. I just looked at
>> -devel and saw the website docs and didn't look further. It
>> seems we're duplicating website in both -docs and -devel
>> which is bad. We should remove those website docs from -devel
>> and have all docs related stuff in -docs
> 
> Duplication is indeed bad.  But notice this guideline:
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Documentation
> 
> Any relevant documentation included in the source distribution should be
> included in the package as %doc. Irrelevant documentation include build
> instructions, the omnipresent INSTALL file containing generic build
> instructions, for example, and documentation for non-Linux systems, e.g.
> README.MSDOS. Pay also attention about which subpackage you include
> documentation in, for example API documentation belongs in the -devel
> subpackage, not the main one. Or if there's a lot of documentation,
> consider putting it into a subpackage. In this case, it is recommended
> to use *-doc as the subpackage name, and Documentation as the value of
> the Group tag.
> 
> I'm wondering if the API docs should live in -devel, and all other files
> in -docs; or we could just have ALL docs live in -docs, as well as make
> -devel depend on -docs.
> 

Currently all the API files are in -docs, with -devel having a dep on -docs,
so I'll leave it that way. Upcoming patch uses danpb's suggesting of COPYING*
in -client and everything else (AUTHORS, ChangeLog, etc). in -docs

Thanks,
Cole




More information about the libvir-list mailing list