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. The buildsystem does other stuff as
well, like trimming the changelog and hardcoding Packager and Vendor
information. (Yes, I like to have that in the SPEC file explicitely)
In fact, I have a set of scripts in a plugin directory that are being
called at different stages. These are being called on the SPEC file
content.
> 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 :)
If mock can add the disttag, I don't see a need to have it as a macro. It
is not something you use for anything else. (Unlike our use of the
disttag)
Kind regards,
-- dag wieers, dag(a)wieers.com,
http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]