Re: [MiNT] RPM Targets for binaries

[Paul Wratt <paul.wratt@gmail.com>]

2010/6/18 Vincent Rivière <vincent.riviere@freesbee.fr>:
> Keith Scroggins wrote:
>>
>> The biggest problem arises when a package is a mixture of libs and
>> binaries, not sure, yet, what to do for it.  Multiple dev libs for each
>> target will cause RPM issues since headers will conflict between them if you
>> want multiple CPU targets.
>
> We should follow the following rules:
>
> 1) 1 source package -> many binary packages
>
> 2) Includes and static libraries should only go into -dev binary packages.
> Such packages should include all the multilib versions, in order to
> encourage people to produce other libraries and executables for all the
> multilib alternatives.
>
> 3) Executables should have their own binary packages, with man/info pages.
> Basically with everything required to run the programs, but without any
> development stuff like includes, etc. Such executables should be optimized
> for one specific multilib only. For example, Falcon users will install the
> 68020-60 executables, they don't care about 68000 or ColdFire programs which
> will be either less efficient or not runnable.
>
> I believe RPM-based Linux distributions are probably already designed like
> this, isn't it ? Thus we would just have to follow their packaging
> conventions, adapted for multilib.
>
> --
> Vincent Rivière
>
surely there is something posix related that can give a definitive
result for CPU type, which both make and RPM can use.

Is this the issue that Keith is having, detecting CPU accurately from
RPM spec file?

or (with regard to make usage) is this the point of ./configure, to
predetermine the CPU type so make does not have to?

is it better (?) for Atari based distros to set a specific environment
variable which is CPU accurate for the system it is running on?

And then make use of this within Makefile's and RPM spec files.


Paul