On Thu, 2010-07-08 at 08:04 +0200, Ralf Corsepius wrote:
> On 07/08/2010 06:59 AM, Panu Matilainen wrote:
> > On Thu, 8 Jul 2010, James Antill wrote:
> >
> >> On Wed, 2010-07-07 at 21:50 -0400, Braden McDaniel wrote:
> >>
> >>> Well, with respect to what to do about a guideline for BuildRequires and
> >>> %{?_isa}, I'm back to being confused.
> >>>
> >>> Matthias' comment suggests to me that %{?_isa} should be recommended in
> >>> BuildRequires for non-noarch packages; but the ensuing discussion makes
> >>> me less certain of that. The result of this uncertainty is that I'm
> >>> back to thinking that mention of BuildRequires should be dropped from
> >>> this draft and its issues deferred to another one.
> >>
> >> _isa in BuildRequires doesn't work atm. and shouldn't be used. There
> >> are possible fixes, but all of them are non-trivial.
> >
> > "Doesn't work" is, err, rather vague.
> >
> > ISA in BuildRequires works just fine (buildsys and all). BUT using it in
> > Fedora infrastructure breaks the SRPM repository& its users (like
> > yum-builddep) which are built under the assumption SRPMs are
> > arch-independent.
>
> Explicit %_isa in any "*requires:" breaks updates when a package changes
> its architecture (noarch <-> "arch").
This strikes me as an uncommon (if not rare) occurrence. Nonetheless...
If your package changes from noarch -> arch, the potential to maintain
compatibility with dependents (without a rebuild) is highly suspect.
Regardless, this is a situation that must be coordinated with downstream
packages.
Changing from arch -> noarch probably stands a better chance of not
introducing breakage on its own; especially if the "arch"-ness was a
mistake or happenstance (e.g., the introduction of noarch subpackages
gave us some such transitions). In cases where "arch"-ness is a mistake
or happenstance, the recommendations in this draft do not advise
dependents to use arch-specific Requires.
If there were a real transition of a *library or -devel* package from
being arch-specific to arch-independent, once again I am very doubtful
that compatibility with dependents could be maintained.
--
Braden McDaniel <braden@xxxxxxxxxxxxx>
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
