Doc dir related changes coming up

[Michael J Gruber]

Michael J Gruber venit, vidit, dixit 08.08.2013 16:03:
> Kevin Fenzi venit, vidit, dixit 07.08.2013 18:39:
>> On Tue, 6 Aug 2013 17:53:22 +0200
>> Till Maas <opensource at till.name> wrote:
>>
>>> On Fri, Jul 26, 2013 at 11:25:19AM +0300, Ville Skyttä wrote:
>>>
>>>> The special (pathless) %doc macro now installs docs to unversioned
>>>> /usr/share/doc/%{name} dir in Rawhide. Packages that don't refer to
>>>> their doc dir by any other means do not need any changes, just a
>>>> rebuild.
>>>>
>>>> Packages that do refer to their doc dir by some other means will
>>>> need changes. It depends on the package if not addressing this will
>>>> result in a build failure or docs still being installed into "wrong"
>>>> (versioned) dirs. Either way the suggested way to handle this is by
>>>> using the %{_pkgdocdir} macro which is now in Rawhide, in
>>>> redhat-rpm-config >= 9.1.0-50.fc20. I'm guessing that this macro
>>>> might be backported to earlier Fedora releases (where it'll expand
>>>> to a dir appropriate for those releases) too at some point, but it
>>>> is unclear when, and also unclear if it will make it into EPEL.
>>>> Luckily handling
>>>
>>> Why is it so hard to just backport this change? And if it needs to be
>>> decided why does FESCO not just do it? Or who needs to decide it?
>>
>> Well, The redhat-rpm-config maintainer is on vacation right now. 
>>
>> I guess I could push an update to earlier releases, do you have a
>> tested patch? ;) 
>>
>> kevin
> 
> Now I'm even more confused by:
> 
> https://fedoraproject.org/wiki/Changes/UnversionedDocdirs
> 
> Building an F20 (master) package on F18 does not work, then, even with
> the proposed conditional %{_pkgdocdir}. Wouldn't a conditional based on
> the Fedora version be a much more robust suggestion to deal with this?
> 
> Michael
> 

[Sorry for the self-reply]

In fact, actually making use og git and its branches and having
different spec files in different branches (by merging different feature
branches) would be the really robust way of doing it. Though the way we
do the branches doesn't exactly help (because we merge master down to
earlier releases).

Michael