building nvmetcli in buildroot

building nvmetcli in buildroot

[stephane gonauer]

Hello,

I would like to embed nvmetcli into a buildroot project of mine. So I
wrote the first patch (0001-package-add-nvmetcli-package.patch) to
include the nvmetcli as a package .

However this doesn't work well because the setup.cfg from your tree
ends up causing buildroot to try to copy nvmetcli.py to the *HOST*
/usr/sbin.

I looked around other python packages built in my configuration and
no-one seems to use the same "install_scripts" keyword.

So I made the second patch (0001-build-remove-setup.cfg.patch) which
applies against the current nvmetcli tree. With this one, buildroot
does work but the script is placed into /usr/bin.

I wonder if this patch could be applied to your tree or if a better
solution exists.


St?phane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-package-add-nvmetcli-package.patch
Type: text/x-patch
Size: 2281 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20171109/517df33f/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-build-remove-setup.cfg.patch
Type: text/x-patch
Size: 753 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20171109/517df33f/attachment-0003.bin>

building nvmetcli in buildroot

[Christoph Hellwig]

I'm perfectly happy to make life for buildroots easier, but nvmetcli
is an admin tool that should live in /usr/sbin.  We'll need to find
a way for that to still be the default.

building nvmetcli in buildroot

[stephane gonauer]

Hi,

I dug further into the question to better understand.

>From my understanding the root cause lies in setuptools :

- buildroot uses --prefix option to set the prefix to $(TARGET_DIR)
- the setup.cfg from nvmetcli uses -install-script
- When both options are present, install-script completely overrides
--prefix and is considered as an absolute path.

I tried to uses $(TARGET_DIR) inside setup.cfg but it is not evaluated
when reaching setup.cfg (and it results in a path containing the
TARGET_DIR and not its value).

Unless someone knows how to better use setuptools, I don't see a
solution inside nvmetcli tree

St?phane

2017-11-09 18:10 GMT+01:00 Christoph Hellwig <hch at lst.de>:
> I'm perfectly happy to make life for buildroots easier, but nvmetcli
> is an admin tool that should live in /usr/sbin.  We'll need to find
> a way for that to still be the default.

building nvmetcli in buildroot

[Christoph Hellwig]

On Fri, Nov 10, 2017@08:43:05AM +0100, stephane gonauer wrote:
> Hi,
> 
> I dug further into the question to better understand.
> 
> >From my understanding the root cause lies in setuptools :
> 
> - buildroot uses --prefix option to set the prefix to $(TARGET_DIR)
> - the setup.cfg from nvmetcli uses -install-script
> - When both options are present, install-script completely overrides
> --prefix and is considered as an absolute path.
> 
> I tried to uses $(TARGET_DIR) inside setup.cfg but it is not evaluated
> when reaching setup.cfg (and it results in a path containing the
> TARGET_DIR and not its value).
> 
> Unless someone knows how to better use setuptools, I don't see a
> solution inside nvmetcli tree

What do other python tools that install into sbin or similar use?
There must be all kinds of precedence for this..

building nvmetcli in buildroot

[Mauro Rodrigues]

On Fri, Nov 10, 2017@08:43:05AM +0100, stephane gonauer wrote:
> Hi,
> 
> I dug further into the question to better understand.
> 
> From my understanding the root cause lies in setuptools :
> 
> - buildroot uses --prefix option to set the prefix to $(TARGET_DIR)
> - the setup.cfg from nvmetcli uses -install-script
> - When both options are present, install-script completely overrides
> --prefix and is considered as an absolute path.
> 
> I tried to uses $(TARGET_DIR) inside setup.cfg but it is not evaluated
> when reaching setup.cfg (and it results in a path containing the
> TARGET_DIR and not its value).
> 
> Unless someone knows how to better use setuptools, I don't see a
> solution inside nvmetcli tree
> 
> St?phane

>From the top of my head I don't recall to see a different solution for
this.

Is your buildroot tool opensource? I would like to see how it deals
with python packages.

Also, I'll take a look if there is a different option from setuptools
standpoint.
> 
> 2017-11-09 18:10 GMT+01:00 Christoph Hellwig <hch at lst.de>:
> > I'm perfectly happy to make life for buildroots easier, but nvmetcli
> > is an admin tool that should live in /usr/sbin.  We'll need to find
> > a way for that to still be the default.
> 

building nvmetcli in buildroot

[stephane gonauer]

Hi,

We are using official buildroot 2017.08.

The build I made was for a not yet open source target but the issue
should be the same on a standard x86 buildroot.
(And we didn't patch build infrastructure for that target)

St?phane

2017-11-10 12:17 GMT+01:00 Mauro Rodrigues <maurosr at linux.vnet.ibm.com>:
> On Fri, Nov 10, 2017@08:43:05AM +0100, stephane gonauer wrote:
>> Hi,
>>
>> I dug further into the question to better understand.
>>
>> From my understanding the root cause lies in setuptools :
>>
>> - buildroot uses --prefix option to set the prefix to $(TARGET_DIR)
>> - the setup.cfg from nvmetcli uses -install-script
>> - When both options are present, install-script completely overrides
>> --prefix and is considered as an absolute path.
>>
>> I tried to uses $(TARGET_DIR) inside setup.cfg but it is not evaluated
>> when reaching setup.cfg (and it results in a path containing the
>> TARGET_DIR and not its value).
>>
>> Unless someone knows how to better use setuptools, I don't see a
>> solution inside nvmetcli tree
>>
>> St?phane
>
> From the top of my head I don't recall to see a different solution for
> this.
>
> Is your buildroot tool opensource? I would like to see how it deals
> with python packages.
>
> Also, I'll take a look if there is a different option from setuptools
> standpoint.
>>
>> 2017-11-09 18:10 GMT+01:00 Christoph Hellwig <hch at lst.de>:
>> > I'm perfectly happy to make life for buildroots easier, but nvmetcli
>> > is an admin tool that should live in /usr/sbin.  We'll need to find
>> > a way for that to still be the default.
>>
>