repotags proposal

[Thorsten Leemhuis]

On 20.05.2007 18:21, Dag Wieers wrote:
> On Sun, 20 May 2007, Thorsten Leemhuis wrote:
>> On 20.05.2007 17:36, Dag Wieers wrote:
>>> On Sun, 20 May 2007, Thorsten Leemhuis wrote:
>>>> On 20.05.2007 16:02, Dag Wieers wrote:
>>>>> On Sun, 20 May 2007, Thorsten Leemhuis wrote:
>>>>>> I wrote a quick proposal for repotags in EPEL. If people really want
>>>>>> repotags in EPEL please speak up in this thread -- I'd really like to
>>>>>> see that contributors really want repotags before I propose this
>>>>>> proposal for voting in a SIG meeting.
>>>>>> == Proposal for the use of repotags for EPEL ==
>>>>>> [...]
>>>>>> == EOF ==
>>>>> That's like saying: we do want to look at it objectively, but here are 
>>>>> some requirements that make it impossible to implement.
>>>> Thanks for your detailed and helpful feedback. I propose this here for
>>>> discussion. So if you have a technical solution that could work, but
>>>> does not confirm to the points of the proposal? Then please show or
>>>> explain it, that we can consider adjusting the proposal before it's
>>>> being voted upon. That why I posted it for discussion.
>>> Well, in our case the buildsystem takes care of adding the repotag.
>> Just out of interest: how?
> Rewriting the SPEC file before using. [...]

Well, that or something similar could be done in the scripts that create
the srpm. That would be acceptable (and, btw, not directly "buildsystem"
in Fedora-land).

>>> Since 
>>> it needs to come at the very last there's no problem doing that. And it 
>>> does not affect anyone maintaining the SPEC files. What's more you can 
>>> leave it out for the Fedora builds, and add it for the EPEL builds.
>> Well, I could live with the buildsys adding it. But I'd prefer not to go
>> with special patches, thus I'd would be best if patches that make this
>> work get integrated directly into mock.
>> But:
>>>> Ohh, sorry, I nearly forgot: there is a technical solution that could
>>>> work. I outlined it in
>>>> https://www.redhat.com/archives/fedora-devel-list/2007-April/msg01232.html
>>>>
>>>> In short: add a %{?repotag} to the end of release in all EPEL spec
>>>> files, set that in the EPEL builders (not in the Fedora ones) to ".epel"
>>>> and the solution is there. We could start with it tomorrow -- but we
>>>> need the Fedora Packaging Committee to agree first, as that's
>>>> responsible for stuff like this in Fedora.
>>> This solution will never be accepted by Fedora because of practical 
>>> problems:
>>>     * it must remain possible to simply copy spec files between Fedora and                                           
>>>       EPEL branches without modifications                                                                               
>>>     * the repotag must be used my all packages 
>>> Since it affects all Fedora packagers you will get objections from most
>>> maintainers, especially because it will not be used for Fedora. The 
>>> obvious question will be: 'why introduce it in all SPEC files if we don't 
>>> use it for Fedora ?'.
>> Nobody said that we need to use it everywhere in Fedora-only packages.
>> But it should be allowed there. That afaics should be acceptable
>>
>> A special repotag macro has one benefit (and that's why I currently
>> think it's the best solution): the spec file could be exchanged easily
>> with other repos. Just define the individual repotag and rebuild one
>> spec file in different repos (dag, CentOS Extras, EPEL, <private repos>,
>> ...).
> Well, remember the disttag ? RPMforge was using that and Fedora took the 
> idea and added a dot in the macro that made it impossible to use it the 
> way we did. Broke our implementation and made things incompatible :)

No sorry, didn't know that. That was not nice -- we at Fedora could have
simply used a different name for the macro.

> If mock can add the disttag, I don't see a need to have it as a macro.
> [...]

disttag is optional in Fedora-land and some people (including me) want
it to stay optional.

Cu
thl