repotags proposal
Dag Wieers
dag at wieers.com
Sun May 20 16:21:18 UTC 2007
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 at wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
More information about the epel-devel-list
mailing list