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(a)endoframe.com>