From mint-bounce@lists.fishpool.fi Fri Jun 18 08:53:25 2010 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=rdwdwiqttnfHDEd1dW8n8S2lBXnWNpGWpDUiW5nYQDk=; b=pZE4bQIiQOJObEjE2Ri0XWMV8c1FL6a1F//e0uDKwrwvyATApTjKUcltbM6wMF15tQ r9v3V7r8ZKWoyQNpC3cs4GgegGVKw9AV7Y7t1VonyBinbToTjKg6LzzldO+r/QspBmoE arsNgjg9pATAIXyiAqQfQ7LBIKSIyHhdF/ZP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=QX3urltwXeEW4k4ibgrqCIwD+/PErTYOJcrOECk9qO8TKJnahkZnKunOFsD735Hrsp Qna57U7KGEkvJYoaWDgPwDnpq82ZdKQiU111rchjmePwOC4UpCa+Bmn/rYxrdCTquH+U 1zCMQUUNdw7gQjUD6BHvN3bnIuS4B+HL+W0k8= Message-ID: <4C1B6BBD.3060003@freesbee.fr> Date: Fri, 18 Jun 2010 14:51:09 +0200 From: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: mint Subject: Re: [MiNT] RPM Targets for binaries References: <251a81da50cac24de9469ebb14574961-EhVcX1lFRQVaRwYcDTpQCEFddQZLVF5dQUBFBDBTXF5bVkYJXldoA1VcMl5dRkMKXl9ZQ10=-webmailer2@server05.webmailer.hosteurope.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: vincent.riviere@freesbee.fr Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: 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