[dpdk-dev] dpdk proposal installation process

[Panu Matilainen]

On 10/21/2015 10:15 PM, Olivier MATZ wrote:
> Hi Mario,
>
> On 10/20/2015 11:17 AM, Bruce Richardson wrote:
>> On Tue, Oct 20, 2015 at 12:21:00AM +0000, Arevalo, Mario Alfredo C wrote:
>>> Hi folks,
>>>
>>>        Good day, this is a proposal in order to improve the dpdk install process,
>>> I would like to know your point of view about the next points according to
>>> previous conversations :) in order to create a new patches version.
>>>
>>> 1) I think the first thing that I have to be aware is "compatibility", the
>>> new changes won't affect the current dpdk behaviour.
>
> Yes. As I stated in a previous mail, I think nobody uses the current
> "make install" without specifying T= as the default value is to build
> and install for all targets.
>
> My suggestion is:
>
> - rename the previous "install" target. The name could probably
>    be "mbuild" (for multiple builds). Other ideas are welcome.
>
> - when "make install" is invoked with T= argument, call the mbuild
>    target to have the same behavior than before. This compat layer
>    could be removed in the future.
>
> - when "make install" is invoked without T=, it installs the fhs.

Nice, this sounds like the best of both worlds.

>
>>> 2) Create new makefile rules, these rules is going to install dpdk files in
>>> default paths, however the linux distributions don't use the same paths for their
>>> files, the linux distribution and the architecture can be factor for different
>>> path as Panu commented in previous conversations, he is right, then all variables
>>> could be overridden, the variables names for the user can be included in documentation.
>>> Also an option could be a configuration file for paths, however I'm not sure.
>
> I think having variables is ok.
>
>>> 3) The default paths for dpdk in order to follow a hierarchy, however the variable
>>> with those values can be overridden.
>>>
>>> -install-bin          --> /usr/bin.
>>> -install-headers  --> /usr/include/dpdk
>>> -install-lib           --> /usr/lib64
>
> I remember Panu suggested to have /usr/lib by default.
> I also think /usr/lib a better default value: some distributions
> use /usr/lib for 64 bits libs, but we never have 32 bits libs in
> /usr/lib64.

Yes, just stick /usr/lib there and be done with it, lib64 is not a good 
default for these very reasons.

>>> -install-doc         --> /usr/share/doc/dpdk
>>> -install-mod        --> if RTE_EXEC_ENV=linuxapp then KERNEL_DIR=/lib/modules/$(uname -r)/extra/drivers/dpdk
>>>                                  else KERNEL_DIR=/boot/modules).
>
> I'm not sure KERNEL_DIR is the proper name. Maybe KMOD_DIR?
>
>>> -install-sdk         --> /usr/share/dpdk and call install-headers ).
>>> -install-fhs          --> call install-libraries, install-mod, install-bin and install-doc (maybe install-headers)
>>>
>>> 4) I'm going to take account all feedback about variables, paths etc for the new version :).
>>>
>>> Thank you so much for your help.
>>>
>>>
>>> Mario.
>>
>> Hi Mario,
>>
>> that seems like a lot of commands to add - are they all individually needed?
>>
>> In terms of where things go, should the "usr" part not a) be configurable via
>> a parameter, and b) default to "/usr/local" as that's where user-installed
>> software from outside the packaging system normally gets put.
>
> A PREFIX variable would do the job.
> About the default to /usr or /usr/local, I agree that /usr/local looks
> more usual, and I don't think it's a problem for packaging as soon as
> it can be overridden.

Yeah, PREFIX support would be nice, and defaulting that to /usr/local 
would be the right thing.

	- Panu -

>
>
> Regards,
> Olivier
>