From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id BAC226835 for ; Wed, 2 Apr 2014 13:02:48 +0200 (CEST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s32B4KWx001710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Apr 2014 07:04:20 -0400 Received: from lsx.localdomain (vpn1-7-206.ams2.redhat.com [10.36.7.206]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s32B4ISF018743; Wed, 2 Apr 2014 07:04:19 -0400 Message-ID: <533BEEB2.1060903@redhat.com> Date: Wed, 02 Apr 2014 13:04:18 +0200 From: Thomas Graf Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Thomas Monjalon References: <1391529271-24606-1-git-send-email-thomas.monjalon@6wind.com> <1391529271-24606-4-git-send-email-thomas.monjalon@6wind.com> <530DE720.6090804@redhat.com> <2489854.B9BgBzrlJE@xps13> In-Reply-To: <2489854.B9BgBzrlJE@xps13> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 03/16] pkg: add recipe for RPM 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: Wed, 02 Apr 2014 11:02:49 -0000 On 04/02/2014 11:53 AM, Thomas Monjalon wrote: > 2014-02-26 14:07, Thomas Graf: >>> +BuildRequires: kernel-devel, kernel-headers, doxygen >> >> Is a python environment required as well? > > Python is only needed to run some tools on the target. But is is optional. > Do you think it should be written somewhere? Not sure what target is in this context. You only need to list it if a python environment must be present at build time. >> What about calling it just "libdpdk"? > > In this case, it should be libdpdk-core in order to distinguish it from dpdk > extensions. But the name of the project is dpdk so it seems simpler to call it > dpdk-core. > Is the "lib" prefix mandatory for libraries? Not at all. You are free to name the package. The mandatory part is that runtime and development files must be separated and the development files such as headers will go into a -devel package. dpdk-core dpdk-core-devel >> This brings up the question of multiple parallel DPDK installations. >> A specific application linking to library version X will also require >> tools of version X, right? A second application linking against version >> Y will require tools version Y. Right now, these could not be installed >> in parallel. Any chance we can make the runtime version independent? > > Are you thinking about installing different major versions? In my > understanding, we cannot install 2 different minor versions of a package. > As long as there is no stable API, there is no major versions defined. > So don't you think we should speak about it later? That's right, you can't install multiple versions of the same package unless you name them differently. This is why we need to come up with a strategy how to handle naming and upgrades now, before we push it into Fedora. Example: Let's assume we push DPDK 1.6.0 into Fedora as 'dpdk-core' with NVR dpdk-core-1.6.0-1. Let's assume we later push Open vSwitch 2.2 into Fedora which will consume DPDK 1.6.0 via "Requires: dpdk-core = 1.6.0" We can't do dpdk-core >= 1.6.0 because there is no compatibility. DPDK 1.6.1 gets released and we push it as dpdk-core-1.6.1-1. We then push dpdk-pktgen into Fedora which is based on DPDK 1.6.1 and requires "dpdk-core = 1.6.1". Users won't be able to install both OVS and dpdk-ptkgen in parallel at this point because they can't install both 1.6.0 and 1.6.1. Fedora inclusion will require a strategy to resolve this. A unique name for each release is an option (Every DPDK release is currently a new major release). This can slowly transform into compatible releases once stable ABIs are in place. Unique names is not enough though as multiple packages would still attempt to install the same file, e.g. header files. This would be typically resolved by installing headers and other non versioned files with a prefix as outlined below. This leaves the problems of tool versioning as they also seem to be bound to specific DPDK versions but can't be prefixed as they need to be part of $PATH. So while we don't have to enforce stable ABIs at this point we have to account for the lack of it in the packaging names and packaging structure. Packages could be named dpdk-1.6.0-core dpdk-1.6.0-core-devel .... https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming >> Same applies to header files. A good option here would be to install >> them to /usr/include/libdpdk{version}/ and have a dpdk-1.5.2.pc which >> provides Cflags: -I${includedir}/libdpdk${version} > > Yes same applies :) > I agree that a .pc file would be a good idea. But we also must allow to build > with the DPDK framework. Definitely.