From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by dpdk.org (Postfix) with ESMTP id F075368B9 for ; Wed, 2 Apr 2014 11:52:18 +0200 (CEST) Received: by mail-wi0-f176.google.com with SMTP id r20so6748766wiv.3 for ; Wed, 02 Apr 2014 02:53:53 -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=EzpKINZ4sJbUCSI7SdtUsqXrFZkiFEPMU0Iw/c1wjQQ=; b=BygNvdag9txtThkEEGVBMrYihRfNoKE4QJ8agxNzV3Y31pID/0bMe7YmOPmfSWORY2 jijXvlvJz48W3L6iYRkT7reJqPK+y5/YLLskrtexV1/+y2pAGfXNc1OaAPmpb1gBybgj RJQ2nGeiGav6iHmiy9Rd8sztYTn69i4eYXLXlVL+/InhtPGSSun5stq8h/2aEF+au8yI oEuTXTfNBeKbst5JjE+X4aY0fTSm3yKEgDES0beVlHOMF45y9FVSpMfRLcm2DYCo+2cS 3O3/LNcgGrI+/9nu0X+TWarhTsNUiCdVbOjnnyQwqt3HCb346STDSowcnbc1ZYBWgS8J b4mQ== X-Gm-Message-State: ALoCoQn8RVs1UiYhWlxGriOrAEfKioUvjxhkgUpn3UvVd6vOd8TNutx8V/Yf0yGjk3o3xd+PzE4Z X-Received: by 10.194.238.231 with SMTP id vn7mr11951944wjc.76.1396432433631; Wed, 02 Apr 2014 02:53:53 -0700 (PDT) Received: from xps13.localnet (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id cv4sm2144942wjc.34.2014.04.02.02.53.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Apr 2014 02:53:52 -0700 (PDT) From: Thomas Monjalon To: Thomas Graf Date: Wed, 02 Apr 2014 11:53:51 +0200 Message-ID: <2489854.B9BgBzrlJE@xps13> Organization: 6WIND User-Agent: KMail/4.12.3 (Linux/3.13.7-1-ARCH; KDE/4.12.3; x86_64; ; ) In-Reply-To: <530DE720.6090804@redhat.com> 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> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 09:52:19 -0000 Hello, Sorry for the long delay. 2014-02-26 14:07, Thomas Graf: > On 02/04/2014 04:54 PM, Thomas Monjalon wrote: > > +Version: 1.5.2r1 > > +Release: 1 > > What kind of upgrade strategy do you have in mind? > > I'm raising this because Fedora and other distributions will require > a unique package name for every version of the package that is not > backwards compatible. > > Typically libraries provide backwards compatible within a major release, > i.e. all 1.x.x releases would be compatible. I realize that this might > not be applicable yet but maybe 1.5.x? > > Depending on the versioning schema the name would be dpdk15, dpdk16, ... > or dpdk152, dpdk153, ... We are working on this but at the moment there is no restriction on API/ABI breakage. So I think it's too early to define such rule. > > +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? > > +%description > > +Dummy main package. Make only subpackages. > > I would just call the main package "libdpdk152" so you don't have to > repeat the encoding versioning in all the subpackages. > > > + > > +%package core-runtime > > 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? > > +%files core-runtime > > +%dir %{datadir} > > +%{datadir}/config > > +%{datadir}/tools > > +%{moddir}/* > > +%{_sbindir}/* > > +%{_bindir}/* > > +%{_libdir}/*.so > > 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? > 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. > You'll also need for all packages and subpackages installing shared > libraries: > > %post -p /sbin/ldconfig > %postun -p /sbin/ldconfig OK Thanks for the review -- Thomas