Patchwork [6/6] package/mtools: new host-package

login
register
mail settings
Submitter Yann E. MORIN
Date March 7, 2013, 9:55 p.m.
Message ID <296699691239a90d5118c5cbe72f1ff57b3761a5.1362693294.git.yann.morin.1998@free.fr>
Download mbox | patch
Permalink /patch/225976/
State Changes Requested
Headers show

Comments

Yann E. MORIN - March 7, 2013, 9:55 p.m.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

---
v1 -> v2
  - remove extraneous spaces, use $(BR2_GNU_MIRROR)  (Thomas)
---
 package/Config.in.host        |    1 +
 package/mtools/Config.in.host |    9 +++++++++
 package/mtools/mtools.mk      |   15 +++++++++++++++
 3 files changed, 25 insertions(+), 0 deletions(-)
 create mode 100644 package/mtools/Config.in.host
 create mode 100644 package/mtools/mtools.mk
Thomas Petazzoni - March 10, 2013, 11:49 a.m.
Yann, Luca,

Cc'ing Luca, there is a licensing infrastructure question below.

On Thu,  7 Mar 2013 22:55:31 +0100, Yann E. MORIN wrote:

> +MTOOLS_VERSION  = 4.0.18
> +MTOOLS_SOURCE   = mtools-$(MTOOLS_VERSION).tar.bz2
> +MTOOLS_SITE     = $(BR2_GNU_MIRROR)/mtools/

MTOOLS_LICENSE = GPLv3+
MTOOLS_LICENSE_FILES = COPYING

However, this makes me realize that we don't distinguish host packages
from target packages in the manifest.csv file. For example, once I had
the licensing informations for this mtools file, I have the following
line in my manifest.csv:

"mtools","4.0.18","GPLv3+","COPYING","mtools-4.0.18.tar.bz2"

And then, someone might think "damn, I have some GPLv3 software in my
system, I now need to comply with the additional special requirements
of GPLv3", while in fact it's not the case (as far as I know) because
mtools is not distributed on the embedded device. Maybe we need to
explicit which packages are on the target, which packages are on the
host, and which packages are on both, no?

Best regards,

Thomas
Yann E. MORIN - March 11, 2013, 12:02 a.m.
Thomas, Luca, All,

On Sunday 10 March 2013 Thomas Petazzoni wrote:
> On Thu,  7 Mar 2013 22:55:31 +0100, Yann E. MORIN wrote:
> 
> > +MTOOLS_VERSION  = 4.0.18
> > +MTOOLS_SOURCE   = mtools-$(MTOOLS_VERSION).tar.bz2
> > +MTOOLS_SITE     = $(BR2_GNU_MIRROR)/mtools/
> 
> MTOOLS_LICENSE = GPLv3+
> MTOOLS_LICENSE_FILES = COPYING

Done.

> However, this makes me realize that we don't distinguish host packages
> from target packages in the manifest.csv file. For example, once I had
> the licensing informations for this mtools file, I have the following
> line in my manifest.csv:
> 
> "mtools","4.0.18","GPLv3+","COPYING","mtools-4.0.18.tar.bz2"
> 
> And then, someone might think "damn, I have some GPLv3 software in my
> system, I now need to comply with the additional special requirements
> of GPLv3", while in fact it's not the case (as far as I know) because
> mtools is not distributed on the embedded device. Maybe we need to
> explicit which packages are on the target, which packages are on the
> host, and which packages are on both, no?

Yes, fully agreed; this would be very puzzling.

I would suggest that we not install licensing information about host
packages, unless they are also used on the target.

Regards,
Yann E. MORIN.
Thomas Petazzoni - March 11, 2013, 9:30 p.m.
Dear Yann E. MORIN,

On Mon, 11 Mar 2013 01:02:06 +0100, Yann E. MORIN wrote:

> I would suggest that we not install licensing information about host
> packages, unless they are also used on the target.

That would make sense, IMO.

Thomas
Luca Ceresoli - March 12, 2013, 5:16 p.m.
Yann E. MORIN wrote:
 > Thomas, Luca, All,
 >
 > On Sunday 10 March 2013 Thomas Petazzoni wrote:
 >> On Thu,  7 Mar 2013 22:55:31 +0100, Yann E. MORIN wrote:
 >>
 >>> +MTOOLS_VERSION  = 4.0.18
 >>> +MTOOLS_SOURCE   = mtools-$(MTOOLS_VERSION).tar.bz2
 >>> +MTOOLS_SITE     = $(BR2_GNU_MIRROR)/mtools/
 >>
 >> MTOOLS_LICENSE = GPLv3+
 >> MTOOLS_LICENSE_FILES = COPYING
 >
 > Done.
 >
 >> However, this makes me realize that we don't distinguish host packages
 >> from target packages in the manifest.csv file. For example, once I had
 >> the licensing informations for this mtools file, I have the following
 >> line in my manifest.csv:
 >>
 >> "mtools","4.0.18","GPLv3+","COPYING","mtools-4.0.18.tar.bz2"
 >>
 >> And then, someone might think "damn, I have some GPLv3 software in my
 >> system, I now need to comply with the additional special requirements
 >> of GPLv3", while in fact it's not the case (as far as I know) because
 >> mtools is not distributed on the embedded device. Maybe we need to
 >> explicit which packages are on the target, which packages are on the
 >> host, and which packages are on both, no?
 >
 > Yes, fully agreed; this would be very puzzling.
 >
 > I would suggest that we not install licensing information about host
 > packages, unless they are also used on the target.

It would probably be sound in most cases, but not compliant to some
licenses, at least if there isa GPL package on the target.
Take what the GPLv2 saysin clause 3:

 > The source code for a work means the preferred form of the work for
 > making modifications to it.  For an executable work, complete source
 > code means all the source code for all modules it contains, plus any
 > associated interface definition files, plus the scripts used to
 > control compilation and installation of the executable.

What do the "scripts used to control compilation and installation"?
We use a toolchain, the autotools, CMake, Python etc on the host to build
packages. While these tools are arguably more complex than the average
"script", they are "used to control the cpmpilation and installation".

Reading on:

 >   However, as a
 > special exception, the source code distributed need not include
 > anything that is normally distributed (in either source or binary
 > form) with the major components (compiler, kernel, and so on) of the
 > operating system on which the executable runs, unless that component
 > itself accompanies the executable.

While this is saying you do not need to redistribute the Debian compiler,
it is using "compiler" and "kernel" as two examples of the "scripts used
to control compilation and installation". Hence my understanding that the
toolchain should be redistributed, along with all of the host tools that
are used to build anything on the target.

As far as the mtools are concerned, they are probably not used to produce
the executables on the target, so they actually do not need to be in the
redistribution list. But most other host packages are different.

Indeed, in the practice I'm retty sure almost nobody modify autotools,
or CMake or other host packages, so even redistributing them would not
disclose much industrial secret.

Bottom line, I think it would be useful to save in the package manifest
an additional column stating whether the package is on the target, on
the host, or both. But skipping host-only packages is not safe.

Luca
Thomas De Schampheleire - March 12, 2013, 5:40 p.m.
Hi,

On Tue, Mar 12, 2013 at 6:16 PM, Luca Ceresoli <luca@lucaceresoli.net> wrote:
> Yann E. MORIN wrote:
>> Thomas, Luca, All,
>>
>> On Sunday 10 March 2013 Thomas Petazzoni wrote:
>>> On Thu,  7 Mar 2013 22:55:31 +0100, Yann E. MORIN wrote:
>>>
>>>> +MTOOLS_VERSION  = 4.0.18
>>>> +MTOOLS_SOURCE   = mtools-$(MTOOLS_VERSION).tar.bz2
>>>> +MTOOLS_SITE     = $(BR2_GNU_MIRROR)/mtools/
>>>
>>> MTOOLS_LICENSE = GPLv3+
>>> MTOOLS_LICENSE_FILES = COPYING
>>
>> Done.
>>
>>> However, this makes me realize that we don't distinguish host packages
>>> from target packages in the manifest.csv file. For example, once I had
>>> the licensing informations for this mtools file, I have the following
>>> line in my manifest.csv:
>>>
>>> "mtools","4.0.18","GPLv3+","COPYING","mtools-4.0.18.tar.bz2"
>>>
>>> And then, someone might think "damn, I have some GPLv3 software in my
>>> system, I now need to comply with the additional special requirements
>>> of GPLv3", while in fact it's not the case (as far as I know) because
>>> mtools is not distributed on the embedded device. Maybe we need to
>>> explicit which packages are on the target, which packages are on the
>>> host, and which packages are on both, no?
>>
>> Yes, fully agreed; this would be very puzzling.
>>
>> I would suggest that we not install licensing information about host
>> packages, unless they are also used on the target.
>
> It would probably be sound in most cases, but not compliant to some
> licenses, at least if there isa GPL package on the target.
> Take what the GPLv2 saysin clause 3:
>
>> The source code for a work means the preferred form of the work for
>> making modifications to it.  For an executable work, complete source
>> code means all the source code for all modules it contains, plus any
>> associated interface definition files, plus the scripts used to
>> control compilation and installation of the executable.
>
> What do the "scripts used to control compilation and installation"?
> We use a toolchain, the autotools, CMake, Python etc on the host to build
> packages. While these tools are arguably more complex than the average
> "script", they are "used to control the cpmpilation and installation".
>
> Reading on:
>
>>   However, as a
>> special exception, the source code distributed need not include
>> anything that is normally distributed (in either source or binary
>> form) with the major components (compiler, kernel, and so on) of the
>> operating system on which the executable runs, unless that component
>> itself accompanies the executable.
>
> While this is saying you do not need to redistribute the Debian compiler,
> it is using "compiler" and "kernel" as two examples of the "scripts used
> to control compilation and installation". Hence my understanding that the
> toolchain should be redistributed, along with all of the host tools that
> are used to build anything on the target.
>
> As far as the mtools are concerned, they are probably not used to produce
> the executables on the target, so they actually do not need to be in the
> redistribution list. But most other host packages are different.
>
> Indeed, in the practice I'm retty sure almost nobody modify autotools,
> or CMake or other host packages, so even redistributing them would not
> disclose much industrial secret.
>
> Bottom line, I think it would be useful to save in the package manifest
> an additional column stating whether the package is on the target, on
> the host, or both. But skipping host-only packages is not safe.

I follow Luca's reasoning here. As we discussed on the Buildroot
Developer Day 2012, we will include the toolchain/host sources
precisely for the above reasons, and so they should be described in a
manifest. I also agree with Thomas' point about the confusion.

But, instead of an extra column, wouldn't it be more clear to separate
the legal-license manifest files for host and target packages? This
would result in a manifest-host.csv and manifest.csv. Packages that
appear on both host and target, would be present in both files. An end
user that is only interested in getting a list of target packages, can
find that info in a glance.

Best regards,
Thomas
Arnout Vandecappelle - March 12, 2013, 11:24 p.m.
On 03/12/13 18:40, Thomas De Schampheleire wrote:
> Hi,
>
> On Tue, Mar 12, 2013 at 6:16 PM, Luca Ceresoli <luca@lucaceresoli.net> wrote:
[snip]
>> Bottom line, I think it would be useful to save in the package manifest
>> an additional column stating whether the package is on the target, on
>> the host, or both. But skipping host-only packages is not safe.

  I agree. And I have a second reason for that: I have one customer who 
distributes an "SDK", i.e. host packages.


> I follow Luca's reasoning here. As we discussed on the Buildroot
> Developer Day 2012, we will include the toolchain/host sources
> precisely for the above reasons, and so they should be described in a
> manifest. I also agree with Thomas' point about the confusion.
>
> But, instead of an extra column, wouldn't it be more clear to separate
> the legal-license manifest files for host and target packages? This
> would result in a manifest-host.csv and manifest.csv. Packages that
> appear on both host and target, would be present in both files. An end
> user that is only interested in getting a list of target packages, can
> find that info in a glance.

  Very good idea.

  Regards,
  Arnout
Thomas Petazzoni - March 15, 2013, 11:48 a.m.
Dear Arnout Vandecappelle,

On Wed, 13 Mar 2013 00:24:31 +0100, Arnout Vandecappelle wrote:

> > But, instead of an extra column, wouldn't it be more clear to separate
> > the legal-license manifest files for host and target packages? This
> > would result in a manifest-host.csv and manifest.csv. Packages that
> > appear on both host and target, would be present in both files. An end
> > user that is only interested in getting a list of target packages, can
> > find that info in a glance.
> 
>   Very good idea.

I don't know if creating a separate file is needed. Maybe just a need
field in the CSV that says if it's a host package only, target package
only, or both. But that's a minor detail, I don't have a strong opinion
between a single CSV file, and two CSV files, as long as it is possible
to identify what is on the target and what isn't.

Best regards,

Thomas

Patch

diff --git a/package/Config.in.host b/package/Config.in.host
index e97f6e8..7c0dd20 100644
--- a/package/Config.in.host
+++ b/package/Config.in.host
@@ -6,6 +6,7 @@  source "package/e2fsprogs/Config.in.host"
 source "package/genimage/Config.in.host"
 source "package/genpart/Config.in.host"
 source "package/lpc3250loader/Config.in.host"
+source "package/mtools/Config.in.host"
 source "package/omap-u-boot-utils/Config.in.host"
 source "package/openocd/Config.in.host"
 source "package/sam-ba/Config.in.host"
diff --git a/package/mtools/Config.in.host b/package/mtools/Config.in.host
new file mode 100644
index 0000000..d534b5e
--- /dev/null
+++ b/package/mtools/Config.in.host
@@ -0,0 +1,9 @@ 
+config BR2_PACKAGE_HOST_MTOOLS
+	bool "host mtools"
+	help
+	  Mtools is a collection of utilities to access MS-DOS disks from
+	  Unix without mounting them. It supports Win'95 style long file
+	  names, OS/2 Xdf disks and 2m disks (store up to 1992k on a high
+	  density 3 1/2 disk).
+	  
+	  http://www.tux.org/pub/tux/mtools/
diff --git a/package/mtools/mtools.mk b/package/mtools/mtools.mk
new file mode 100644
index 0000000..1542799
--- /dev/null
+++ b/package/mtools/mtools.mk
@@ -0,0 +1,15 @@ 
+#############################################################
+#
+# dosfstools
+#
+#############################################################
+
+MTOOLS_VERSION  = 4.0.18
+MTOOLS_SOURCE   = mtools-$(MTOOLS_VERSION).tar.bz2
+MTOOLS_SITE     = $(BR2_GNU_MIRROR)/mtools/
+
+MTOOLS_CONF_OPT = --enable-xdf        \
+                  --enable-vold       \
+                  --enable-new-vold
+
+$(eval $(host-autotools-package))