On 5/20/07, Jeff Sheltren <sheltren(a)cs.ucsb.edu> wrote:
On May 20, 2007, at 9:49 AM, Thorsten Leemhuis wrote:
>
> The EPEL Steering Committee gives this agreement only as long as
> following points are meet by the technical solution:
>
> * it must remain possible to simply copy spec files between Fedora
> and
> EPEL branches without modifications
>
> * no hacks to the buildsys or modifications to the rpms after their
> initial creation
>
> * the repotag must be used my all packages
>
> * no abuse of the disttag
>
Hi Thorsten, thanks for the proposal. I think that using some macro,
such as %{?repotag}, or even just %{?repo} would be a good start. It
is very easy to implement, and the same specs could still be used in
Fedora without any problems (AFAICS). Adding it to the dist tag does
not make sense to me. However, I am curious to know why you are
against some sort of patch to the build system? It seems that could
also be a nice possible solution.
Aside from my question about having the build system handle the
repotag on its own, I am mostly
+1 for your proposal.
Allow me to add a +1 for discussion of this. Working in an
enterprise
where Admins sometimes pull packages from a variety of sources, having
a repo-tag helps me. I can figure where someone pulled a package.
Our internally built packages also have a repotag (abuse of %dist tag
actually) but it can be seen easily. I understand how to query rpms
for a repo, sadly, many admins/users I work with don't. For the good
of the end-user in EL-land, I support a repo tag. The implementation,
I hope, could be painless .
If EPEL started using repotags, maybe it would drive yum/rpm
developers to evaluate its value again and get the proper coding into
the packaging products. This isn't about right or wrong, it's about
moving in a positive direction for the consumers of EL and ultimately
the new EPEL platform.
stahnma
-Jeff
_______________________________________________
epel-devel-list mailing list
epel-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list