From mint-bounce@lists.fishpool.fi Fri Jun 18 07:50:47 2010 Date: Fri, 18 Jun 2010 07:49:02 -0400 (EDT) From: Keith Scroggins To: Miro Kropacek cc: m0n0 , mint Subject: Re: [MiNT] RPM Targets for binaries In-Reply-To: Message-ID: References: <251a81da50cac24de9469ebb14574961-EhVcX1lFRQVaRwYcDTpQCEFddQZLVF5dQUBFBDBTXF5bVkYJXldoA1VcMl5dRkMKXl9ZQ10=-webmailer2@server05.webmailer.hosteurope.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: kws@radix.net Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: On Fri, 18 Jun 2010, Miro Kropacek wrote: > 1. Why do you set CFLAGS="-m68020-60 ${RPM_OPT_FLAGS}" when > RPM_OPT_FLAGS are already set to m68020-60? I think the example you are speaking of is a m68kmint target, so the CPU needs to be specified. > 2. You begin with rpm -ba make.spec / rpm -ba make.spec --target > m68k020mint / rpm -ba make.spec --target cfmint approach (i.e. build > for each architecture separately) and then you zlib example contains > 3-in-1 rpm? Or did you misunderstand something? With libraries, the Multilib support is easy on the end user, and also simpler just to package everything together. With make being a binary, one binary for each target, with Zlib being a lib, one dev package with all targets. > I really can't decide what's the best option for multilib environment. > Each has its pros and cons... I think one thing needs clarification: > we're talking about devel-only rpm files, right? Because normal rpms > (like 'awk' for example) clearly can be in m68kmint / m68k020mint / > cfmint versions (and conflicting with each other). And about devel > ones containing binaries: would it be really such a big sin to have it > in /usr/bin/m68020-60 and /usr/bin/m5475? Yeah, pure binaries can each be set for their own target, and the user would just pick what they want and be done with it. Dev packages with binaries is where the issue lies. One problem with packing all 3 target binaries is the size. Libraries are definitely a low cost, disk space wise, addition, but binaries start eating space. I was trying to come up with a way to detect installed CPU at install time with RPM, and have a post script run to pick the right binary for the user to not do like you suggest above with CPU specific bin paths, but, so far, did not find something I liked and that would work cleanly. Although, the binary paths could be the best solution. Anyway, I'm going to hopefully patch RPM today for those additional targets and get it tested so can move forward. RPM will most likely need to be patched again once the Coldfire is released.... Keith > > -- > MiKRO / Mystic Bytes > http://mikro.atari.org >