From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by dpdk.org (Postfix) with ESMTP id 4A0A6AFD6 for ; Mon, 19 May 2014 18:28:41 +0200 (CEST) Received: by mail-we0-f178.google.com with SMTP id u56so5649264wes.23 for ; Mon, 19 May 2014 09:28:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=168Sss3lliZSTdvZdU3D1eojc0sc8BSc/qSRbSlNJUY=; b=Tb8juVljFN2XEu68CXvb9Jta5UTgyW9CWtEIyixvYDXFFXuaBKs+Sg8YyCHaLqlED/ f9uYWx+JQdtAqG2M4Cd7G+iRuzhNeu7p5dNm9ut1s73p/rG5C5fAl5M4nMh18E41GSev kJ8Ibw8otXxfPIb9XMVIOYcUkhP74LnDp8FggrgxsymAXv8ZID1Od85ohSVE5m9h/A1P 852WPxek0vbeHx6GKvZSHInymOi9N4RSqCYXMFRdAjRlg8SI2L7qUyL5U/YZLpKRjhHI 4e2qz8+QbI6NuxVDmYaAe92uyg51Dlh1gdLCmI/6Y0K2sHTdXUICHkkid1b2OyQ95pym MfDg== X-Gm-Message-State: ALoCoQlh+nFaeGVB+96xFmP7Ag+rJbMzSsOWixmAfgKJMgRjOUrbBOF47OP98axhBYKlN49l4Os2 X-Received: by 10.180.85.134 with SMTP id h6mr14094243wiz.44.1400516929929; Mon, 19 May 2014 09:28:49 -0700 (PDT) Received: from xps13.localnet (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id p18sm15866812wik.3.2014.05.19.09.28.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 May 2014 09:28:48 -0700 (PDT) From: Thomas Monjalon To: Neil Horman Date: Mon, 19 May 2014 18:28:47 +0200 Message-ID: <1812701.3lMAr9cpVW@xps13> Organization: 6WIND User-Agent: KMail/4.13 (Linux/3.14.4-1-ARCH; KDE/4.13.0; x86_64; ; ) In-Reply-To: <20140519131855.GA2215@hmsreliant.think-freely.org> References: <20140513190840.GB31172@hmsreliant.think-freely.org> <1446205.rSbWAAsRtd@xps13> <20140519131855.GA2215@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Heads up: Fedora packaging plans X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 16:28:41 -0000 2014-05-19 09:18, Neil Horman: > On Mon, May 19, 2014 at 12:11:35PM +0200, Thomas Monjalon wrote: > > My main concerns are about naming and extensions. > > We must keep "dpdk-core" naming in order to distinguish it from PMD > > extensions. > > I don't see why. We can name packages whatever we want, as long as the spec > and srpm share the same name. It seems to me that the core should be the > base name of the package while the extensions should have some extension on > their name. OK > > And then, packaging of memnic and non-uio paravirtualization PMDs > > (virtio/vmxnet3) are missing. > > They're in separate repositories, I was planning on packaging them at a > later time separately, since their versioning and development is handled > separately. OK > > We should try to get .spec for Fedora and in-tree .spec as common as > > possible. There are probably some things to push. > > Ok, sure, just keep in mind that different distributions have different > packaging requirements that may affect the contents of the spec file, and so > attaining parity may not be possible (or even worthwhile). Yes, the in-tree file should be a common base. > > I thought that we should put version in the name, in order to be able to > > install many versions together. How is it handled by yum? > > So, I spent some time thinking about this, and I _really_ want to avoid the > inclusion of a version with the package name. Doing so, while it allows yum > to install multiple versions side-by-side, is a real overhead for me, as it > requires that I go through a new pacakge review process for each released > version that we want to package. I do not have time to do that. If > someone from 6wind or intel wants to get involved in the Packaging process > we can look at that as a solution, but while I'm doing it, its really just > too much overhead. This method will allow multiple version to be installed > side by side as well. The tradeoff is that yum doesn't directly allow > that, as it will just preform an upgrade. The multiple version solution > will require that you download older versions and install them directly > using rpm commands. I think thats a fair tradeoff. OK > > > * Added config files to match desired configs for Fedora (i.e. disabled > > > PMD's that require out of tree kernel modules > > > > It would be clearer to make your configuration changes with "sed -i". > > In a near future we would probably need a "configure" script to do it. > > I really disagree. Its not clearer in my mind at all - in that the final > config file is a product of two pieces of information (the base config > file, and the sed scripts that you run on it), as opposed to one piece (the > canonical modified config specified in the source line). Using sed also > implies that you need to list sed as a BuildRequires (minimal buildroots > may not include sed when they are spun up). I don't understand the logic. When packaging a library using autotools, you are setting some options to "configure" script which are not saved elsewhere than in the spec file, right? Why it wouldn't be the same here (options in spec file)? > > So you don't package igb_uio but you build it because there is no option > > to disable it currently. We should add such option. > > Not sure what you mean here. The only uio code I see in the package is the > uio unbind script for igb, which should still work just fine (save for the > fact that we don't have a user space PMD to attach the hardware to). I can > certainly remove the script though so it doesn't appear in the package > until such time as the LAD group integrates the uio code in the upstream > driver. I'm speaking about lib/librte_eal/linuxapp/igb_uio. I think you are building it and it would fail if you no kernel header installed. -- Thomas