On Thu, 2007-04-26 at 09:04 +0200, Thorsten Leemhuis wrote:
> Use a repotag for EPEL4 and EPEL5 like this: add a "%define repotag foo"
> in the buildsys, where foo expands to ".epel4" in EPEL4 and ".epel5" on
> EPEL5; the repotag macro doesn't get defined in Fedora builders and thus
> nothing will change when building a package for Fedora, even if it has a
> %{?repotag} in %{release}.
Just a tiny detail, picking a random EPEL package:
denyhosts-2.6-4.el5.noarch.rpm
then it would/could become:
denyhosts-2.6-4.el5.epel5.noarch.rpm
which I think is redundant, repotag should expand to "epel" only for all
versions, so we would have:
denyhosts-2.6-4.el5.epel.noarch.rpm
> Then enforce the use of "%{?repotag}" at the end of %{release} for all
> packages in EPEL. To make that effective used in the repo it requires a
> rebuild of all packages that are in EPEL already. Not nice and a bit of
> work, but for the sake of making people happy let's just do it. The
> added "%{?repotag}" in the release field must be allowed in Fedora spec
> files, too, so people can easily copy spec files from Fedora to EPEL and
> vice versa without having to modify them.
Sounds good. The rebuild could happen over a period of time, of course.
Would it be possible to use the already existing %{?dist} distag and
just change the way it is expanded in EPEL alone? That would actually
avoid changing the spec file at all. I don't know if this might be a
technical no-no for some reason in Fedora's build system.
Hmmm, I seem to remember something about incremental releases being set
by a number _after_ the distag... that might make this option a no-go
(AFAIK third party repos - including mine - have used disttag as the
_last_ component of release, so, for example in my case disttag expands
to .fcx.ccrma).
> By Fedora 8 or Fedora 9 enhance the tools (rpm, yum, ...) to display a
> the %{vendor} field in case of problems (for all packages that are
> involved) and in popular queries. Then drop the repotag in EPEL6 and
> later again, as it shouldn't be that much needed anymore
>
> ---
>
> Did I miss anything?
Sounds good to me. I like Jeff's suggestion (further down in the thread)
to eventually use the signature of the package to id the distro:
On Thu, 2007-04-26 at 13:22 -0800, Jeff Spaleta wrote:
> Even the Vendor tag isn't authoritative really. The only way we can
> generally solve this currently this is to rely on the actually package
> signatures and relate those back to signing key ID strings (until
> packages start using a more generalized cert istead of gpg sigs). And
> there doesn't appear to be any way to do that with even an rpm
> commandline argument with the rpm in fedora currently. "Who signed
> this package" is not a question that rpm can reasonably answer as far
> as I can tell. I wouldn't characterize an alpha-numeric key ID in the
> -qi output as user-friendly. I'd love to be able to ask that question
> and get information like the output of rpm -q --qf "%{SUMMARY}\n"
> gpg-pubkey-1ac70ce6-41bebeef.
Looks to me like the right technical solution. Reliable and automatic
(does not depend on the packager to conform to a standard). Obviously
its usefulness depends on how rpm & friends are changed to support it in
a "transparent" way.
-- Fernando
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
