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. > > 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. > > 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 > -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). > -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. /Bruce