On Thu, 8 Jul 2010, seth vidal wrote:
> On Thu, 2010-07-08 at 07:59 +0300, 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.
>>
>
> If srpms are not arch independent then they need to stop being created
> as .src.rpm. I know that they have the arch of what platform they were
> built on stored in the arch tag internally. I also know that if the
> assumption that src.rpm's are not arch independent is now no longer
> accurate then a lot of tooling has to change.
>
> I'm sure the following is what you'll say:
>
> "well, we never made any promises about that and they do have an arch
> contained in them."
>
> That's great - I'm glad we are getting into the legal details of what
> was or was not committed to and not, instead, focusing on what we're
> doing to what we need srpms to do.
SRPMS have never been arch-independent, using %{_isa} in BuildRequires
just makes it much more visible.
There are myriads of ways for an SRPM to be arch-dependent, for example:
%ifarch ppc ppc64
BuildRequires: ppc-utils-devel
%endif
%ifarch x86_64
Source0: foo-64bit.tar.gz
%else
Source1: foo-32bit.tar.gz
%endif
I'm not aware of arch-conditional buildrequires being banned in Fedora (if
they are, I stand corrected), so the first case can already create a SRPM
with dependencies unresolvable outside ppc.
The arch-conditional source is crazy of course, but the spec syntax
permits it.
> If srpms are not arch-independent do you mean to say that we need to
> create separate srpms for each arch we build on?
Nobody, me included, wants that.
One option is to continue the current "it mostly works" way, and just ban
the use of spec constructs that cause arch-dependent dependencies in SRPM.
Actually fixing the issue is going to require more dramatic actions
though and changes to the tools. All sorts of possibilities do exist, for
example:
1) Forget SRPMs, just stuff the sources, patches and spec from a given CVS
tag into a %{name}-%{version}-%{release}.tar.gz tarball and distribute
those instead of SRPMs. There you have a format that's guaranteed to be
arch-independent all the way, and they're buildable too, just
'rpmbuild -tb <tarball>' and go.
2) Create metadata for the SRPMs per-arch, but only actually distribute
one SRPM. Might involve things like splitting header and payload to
separate files or something.
...or something.
If you ask me, I would go for 1). Seriously. If you want metadata to go
with the tarballs, strip the header out of src.rpm's on each arch and
build per-arch metadata only.
- Panu -
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
