Re: repotag in EPEL (was: Re: Plan for tomorrows (20070426) FESCO meeting)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux