Hi

OK, I'll bite.

While I appreciate that your mission is to build source packages, I feel
that you have done so much hard work already to make everything platform
independent, that allowing platform-independent binary packages to be
built is a minuscule extra step. It also seems kind of contrarian to
focus so much on platform independence in every part of the packaging
process, and then not to allow platform independent packages ;-)

In my case I want to package and distribute X509 certificates. There is
no reason while these should be built multiple times from source for
each architecture.

So to answer my own original question, here is a trivial recipe that
makes architecture- and os-independent binary packages possible:
1. In the specfile, add the lines
BuildArch: noarch
%define _target_os anyos

Obviously the package would also be relocatable if the line
Prefix:       %{l_prefix}
is also included.

2. In the rpmrc file (%{l_prefix/etc/openpkg/rpmrc) add an identifier
AnyOS to the end of the "os_compat" lines. E.g.
os_compat:          Linux2.0:   linux2.0 anyos
os_compat:          Linux2.1:   linux2.1 linux2.0 anyos

This is the same way that the "noarch" architecture is handled.

Cheers

Conrad


On Tue, 2003-07-29 at 11:50, Ralf S. Engelschall wrote:
> On Tue, Jul 29, 2003, Conrad Steenberg wrote:
> 
> > I'm trying to build a package consisting only of
> > architecture-independent files, but need some info on package naming:
> >
> > When built with a BuildArch: noarch, the package gets named e.g.
> > mypackage-1.2.3-1.noarch-linux2.4-oo.rpm
> >
> > Is there a way to let the package be named
> > mypackage-1.2.3-1.noarch.rpm or even mypackage-1.2.3-1.noarch-oo.rpm ?
> >
> > The package clearly has nothing to do with Linux or being built in
> > /opt/openpkg.
> 
> There is a technical and an organisational answer:
> 
> 1. Technically:
> 
>    RPM originally defines
> 
>    %_rpmfilename %%{ARCH}/%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm
> 
>    which means that under "BuildArch: noarch" you get binary RPMs
>    named like mypackage-1.2.3-1.noarch.rpm. Because OpenPKG is a
>    cross-platform solution (not just cross-architecture!) we redefined
>    the _rpmfilename to be:
> 
>    %_rpmfilename %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}-%%{OS}-%{id}.rpm
> 
>    and this way the binary RPMs are named like
>    mypackage-1.2.3-1.ix86-linux2.4-oo.rpm. And setting the BuildArch
>    obviously results in mypackage-1.2.3-1.noarch-linux2.4-oo.rpm. So, in
>    short: in OpenPKG you cannot get mypackage-1.2.3-1.noarch.rpm at all.
>    But this doesn't matter from our point, because...
> 
> 2. Organisationally:
> 
>    OpenPKG by design focuses on source RPMs and the building and
>    installing directly from them. Binary RPMs are just an intermediate
>    and temporary result in this approach. From our perspective, they
>    exist just temporarily on the target machine or on our FTP server
>    because of bootstrapping and for emergency situations only. Hence we
>    do not distinguish between architecture independent and dependent
>    binary packages. Binary RPMs make already too much trouble, so the
>    OpenPKG project stays out of this business and tries not to make it
>    more complex than it has to be for us....
> 
> Because this issue should not confuse others in the future, I've added
> two FAQs points about this now ;-)
> 
> http://www.openpkg.org/faq.html#source-focus
> http://www.openpkg.org/faq.html#noarch
> 
>                                        Ralf S. Engelschall
>                                        [EMAIL PROTECTED]
>                                        www.engelschall.com
> 
> ______________________________________________________________________
> The OpenPKG Project                                    www.openpkg.org
> Developer Communication List                   [EMAIL PROTECTED]
-- 

______________________________________________________________________
The OpenPKG Project                                    www.openpkg.org
Developer Communication List                   [EMAIL PROTECTED]

Reply via email to