2:45 p.m.
Simon Schampijer wrote:
Yes. So the main question is now if Fedora would be willing to ship
general licenses under /usr/share/common-licenses, I think.
FWIW, I don't think it's legal to do that, licenses need to accompany the
package.
But in any case what really matters is whether RH Legal thinks it's legal,
not whether you or me do.
Kevin Kofler
3 p.m.
New subject: Full Licence field
On 03/18/2009 03:45 PM, Kevin Kofler wrote:
Simon Schampijer wrote:
> Yes. So the main question is now if Fedora would be willing to ship
> general licenses under /usr/share/common-licenses, I think.
I really don't want to do this. Here's why:
A) Many copyright holders make minor modifications to the licensing
terms. These modifications usually do not affect the rights granted by
the license (which is why we do not mark them as distinct and individual
licenses), but it would be incorrect to have these packages pointing to
general license texts when those do not apply.
B) Many licenses require that any distribution include the license text.
Red Hat Legal was very uncomfortable with us using a rpm dependency to
meet that requirement.
What I do think we were looking at doing is having rpm mark %license
texts in a unique way that is different from %doc. This would permit rpm
--excludedocs but retain the license texts.
~spot
3:44 p.m.
New subject: Full Licence field
On Wed, 2009-03-18 at 16:00 -0400, Tom "spot" Callaway wrote:
On 03/18/2009 03:45 PM, Kevin Kofler wrote:
> Simon Schampijer wrote:
>> Yes. So the main question is now if Fedora would be willing to ship
>> general licenses under /usr/share/common-licenses, I think.
I really don't want to do this. Here's why:
A) Many copyright holders make minor modifications to the licensing
terms. These modifications usually do not affect the rights granted by
the license (which is why we do not mark them as distinct and individual
licenses), but it would be incorrect to have these packages pointing to
general license texts when those do not apply.
B) Many licenses require that any distribution include the license text.
Red Hat Legal was very uncomfortable with us using a rpm dependency to
meet that requirement.
What I do think we were looking at doing is having rpm mark %license
texts in a unique way that is different from %doc. This would permit rpm
--excludedocs but retain the license texts.
Thinking aloud, a couple of other approaches:
(i) Embed the SHA256 checksum of each license into the path e.g.:
/usr/share/common-licenses/32b1062f7da84967e7019d01ab805935caa7ab7321a7ced0e30ebe75e5df1670/COPYING
then have each file's identical implementation of those bytes overwrite
each other, and you might have many packages owning that path on the
installed system. Slight modifications thus lead to different paths.
That way you still have duplicates in the .rpm files, but an installed
system has just one copy of each, and each rpm does indeed ship the
precise license it's required to.
I suspect that the arguments from crypto and from the legal side will
"pass through one another like angry ghosts", though (and legal thus
wins).
(ii) Compress the licenses?
4:33 p.m.
New subject: Full Licence field
On Wed, Mar 18, 2009 at 04:44:10PM -0400, David Malcolm wrote:
Thinking aloud, a couple of other approaches:
(i) Embed the SHA256 checksum of each license into the path e.g.:
/usr/share/common-licenses/32b1062f7da84967e7019d01ab805935caa7ab7321a7ced0e30ebe75e5df1670/COPYING
then have each file's identical implementation of those bytes overwrite
each other, and you might have many packages owning that path on the
installed system. Slight modifications thus lead to different paths.
That way you still have duplicates in the .rpm files, but an installed
system has just one copy of each, and each rpm does indeed ship the
precise license it's required to.
I suspect that the arguments from crypto and from the legal side will
"pass through one another like angry ghosts", though (and legal thus
wins).
(ii) Compress the licenses?
How much disk space do all the separate license files currently take?
My guess is that it is just not going to be worth dealing with
compressing, hardlinking, or sharing copies of identical files with
multiple packages, because the saved disk space will be minimal.
On my installed F10 desktop system here are the sizes of all installed
license files (%doc matching licen|copy|gpl|bsd) combined:
$ echo `rpm -qad | grep -Ei 'licen|copy|gpl|bsd' | xargs stat -c %s` | sed
-e's/ /+/g' | bc
16920051
17 megabytes. Not worth the effort to save space here.
4:43 p.m.
New subject: Full Licence field
On Wed, Mar 18, 2009 at 05:33:12PM -0400, Chuck Anderson wrote:
On Wed, Mar 18, 2009 at 04:44:10PM -0400, David Malcolm wrote:
> Thinking aloud, a couple of other approaches:
> (i) Embed the SHA256 checksum of each license into the path e.g.:
>
/usr/share/common-licenses/32b1062f7da84967e7019d01ab805935caa7ab7321a7ced0e30ebe75e5df1670/COPYING
> then have each file's identical implementation of those bytes overwrite
> each other, and you might have many packages owning that path on the
> installed system. Slight modifications thus lead to different paths.
>
> That way you still have duplicates in the .rpm files, but an installed
> system has just one copy of each, and each rpm does indeed ship the
> precise license it's required to.
>
> I suspect that the arguments from crypto and from the legal side will
> "pass through one another like angry ghosts", though (and legal thus
> wins).
>
> (ii) Compress the licenses?
How much disk space do all the separate license files currently take?
My guess is that it is just not going to be worth dealing with
compressing, hardlinking, or sharing copies of identical files with
multiple packages, because the saved disk space will be minimal.
On my installed F10 desktop system here are the sizes of all installed
license files (%doc matching licen|copy|gpl|bsd) combined:
$ echo `rpm -qad | grep -Ei 'licen|copy|gpl|bsd' | xargs stat -c %s` | sed
-e's/ /+/g' | bc
16920051
17 megabytes. Not worth the effort to save space here.
You're quick to declare that without really thinking about it. I agree
that on a typical desktop setup, 17MiB is pretty insignificant. However
for projects like OLPC, which is a downstream user of Fedora, 17MiB can
be quite a space hit for simple text files.
Now, OLPC has other ways of dealing with this at the moment, but at
some point they won't.
josh
4:09 a.m.
New subject: Full Licence field
On Wed, Mar 18, 2009 at 04:00:05PM -0400, Tom spot Callaway wrote:
B) Many licenses require that any distribution include the license
text.
Red Hat Legal was very uncomfortable with us using a rpm dependency to
meet that requirement.
It's interesting you should mention this. I try to include the
license file in the main package and all subpackages (eg. in foo and
foo-devel), but often reviewers see this as a bug and ask me to
include the license only in the main package.
An example of this, I'm not picking on Jason Tibbitts in particular:
https://bugzilla.redhat.com/show_bug.cgi?id=476622#c11
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
5:17 a.m.
New subject: Full Licence field
Richard W.M. Jones wrote:
It's interesting you should mention this. I try to include the
license file in the main package and all subpackages (eg. in foo and
foo-devel), but often reviewers see this as a bug and ask me to
include the license only in the main package.
This really needs a guideline. Some reviewers are complaining if we don't
put the license in each subpackage, others are complaining if we do. There
needs to be a consistent policy throughout Fedora.
Kevin Kofler
12:01 p.m.
New subject: Full Licence field
>>>> "KK" == Kevin Kofler
<kevin.kofler(a)chello.at> writes:
KK> This really needs a guideline.
It already is. Is the existing guideline somehow unclear? We tried
to write it as clearly as possible. "A Fedora package must not list a
file more than once in the spec file's %files listings." Where does
that leave room for doubt about license files?
- J<
1:03 p.m.
New subject: Full Licence field
On Thu, Mar 19, 2009 at 12:01:38PM -0500, Jason L Tibbitts III wrote:
>>>>> "KK" == Kevin Kofler
<kevin.kofler(a)chello.at> writes:
KK> This really needs a guideline.
It already is. Is the existing guideline somehow unclear? We tried
to write it as clearly as possible. "A Fedora package must not list a
file more than once in the spec file's %files listings." Where does
that leave room for doubt about license files?
The packaging guidelines are clear, but also we might be breaking the
law by distributing binary packages (RPMs) without license files. It
sounds like the packaging guidelines may need to be modified.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
2:30 p.m.
New subject: Full Licence field
>>>> "RWMJ" == Richard W M Jones
<rjones(a)redhat.com> writes:
RWMJ> The packaging guidelines are clear, but also we might be
RWMJ> breaking the law by distributing binary packages (RPMs) without
RWMJ> license files.
As I understand this, the issue has already been through the lawyers;
I asked about it many months ago. But I guess I'll let spot comment
on that.
- J<
4 p.m.
New subject: Full Licence field
On 03/19/2009 03:30 PM, Jason L Tibbitts III wrote:
As I understand this, the issue has already been through the
lawyers;
I asked about it many months ago. But I guess I'll let spot comment
on that.
I think what I will say on this topic is this:
If there is not a clear rpm dependency between a subpackage (e.g.
foo-devel Requires: foo) and the package which contains the License
text, and the license text contains a requirement that it be distributed
along with all binaries, then and only then is it acceptable to
duplicate the License text in multiple subpackages, with the caveat that
it should be in the SAME location in each subpackage.
Note: The GPL/LGPL does require this.
~spot
4:32 p.m.
New subject: Full Licence field
>>>> "TC" == Tom \"spot\" Callaway
<tcallawa(a)redhat.com> writes:
TC> If there is not a clear rpm dependency between a subpackage
TC> (e.g. foo-devel Requires: foo) and the package which contains the
TC> License text, and the license text contains a requirement that it
TC> be distributed along with all binaries, then and only then is it
TC> acceptable to duplicate the License text in multiple subpackages,
TC> with the caveat that it should be in the SAME location in each
TC> subpackage.
Well, in that case I must apologize for those reviews I've done. I
would swear that I had requested an opinion on directly this issue
(even the more specific case where there is no link in name or
dependency between the various packages generated from one src.rpm)
and was told that it was sufficient to include the license text
exactly once. That's the advice I've been going on for some time, and
the guidance I used when voting on the guideline restricting
duplicates.
Oh, well.
- J<
noon
New subject: Full Licence field
>>>> "RWMJ" == Richard W M Jones
<rjones(a)redhat.com> writes:
RWMJ> An example of this, I'm not picking on Jason Tibbitts in
RWMJ> particular:
My objection to this is directly reflected by a guideline.
-----
Duplicate Files
A Fedora package must not list a file more than once in the spec
file's %files listings. If you think your package is a valid exception
to this, please bring it to the attention of the Packaging Committee
so they can improve on this Guideline.
-----
I see no objection for license files.
- J<
8:13 a.m.
New subject: [Sugar-devel] Full Licence field
Tom "spot" Callaway wrote:
On 03/18/2009 03:45 PM, Kevin Kofler wrote:
> Simon Schampijer wrote:
>> Yes. So the main question is now if Fedora would be willing to ship
>> general licenses under /usr/share/common-licenses, I think.
I really don't want to do this. Here's why:
A) Many copyright holders make minor modifications to the licensing
terms. These modifications usually do not affect the rights granted by
the license (which is why we do not mark them as distinct and individual
licenses), but it would be incorrect to have these packages pointing to
general license texts when those do not apply.
B) Many licenses require that any distribution include the license text.
Red Hat Legal was very uncomfortable with us using a rpm dependency to
meet that requirement.
What I do think we were looking at doing is having rpm mark %license
texts in a unique way that is different from %doc. This would permit rpm
--excludedocs but retain the license texts.
~spot
So, the point to ship a license per package is fine. I actually did not
want to relax that. I had the technical problem to need to access the
license field to be able to display it in a dialog inside Sugar.
http://shell.sugarlabs.org/~erikos/licence_field.png
And since - the file is placed in different places on each distro I
wanted to see if a common place would be possible, makes sense. On
Fedora this could have been in addition to the per package license
field. Not very economic of course.
Anyhow - while thinking about it, I was not even sure the displaying of
the full license is correct/needed - or matches the guidelines. For
example I have not seen something similar in GNOME.
Maybe someone from Fedora that has more insights on those legal issues
can comment what they want/need to see in such a page for Sugar on Fedora.
Thanks,
Simon
PS: Of course, thanks for all the interesting comments about compressing
the files etc to gain some space.
7:52 a.m.
New subject: Full Licence field
Tom "spot" Callaway wrote:
On 03/18/2009 03:45 PM, Kevin Kofler wrote:
> Simon Schampijer wrote:
>
>> Yes. So the main question is now if Fedora would be willing to ship
>> general licenses under /usr/share/common-licenses, I think.
>>
I really don't want to do this. Here's why:
A) Many copyright holders make minor modifications to the licensing
terms. These modifications usually do not affect the rights granted by
the license (which is why we do not mark them as distinct and individual
licenses),
Perhaps this is a mistake on our part?
but it would be incorrect to have these packages pointing to
general license texts when those do not apply.
B) Many licenses require that any distribution include the license
text.
Red Hat Legal was very uncomfortable with us using a rpm dependency to
meet that requirement.
Maybe it's because I'm not a lawyer, that I fail to see the problem with
that.
As long as there exists some reference to the license and a location
where it can be read,
doesn't that meet the requirements of those licenses?
It seems awfully wasteful carrying a million or more copies of the same
blasted license file,
in a million or more locations in the OS.
Wasn't there a discussion, somewhat recently, about libraries that are
shipped with the program instead
of being stored in /lib or /usr/lib?
Seems, to me, the arguments used to store such files in a *COMMON
LOCATION* can, and should, be
used here.
Or has common sense been thrown out the window?
Lyos Gemini Norezel
8:36 a.m.
New subject: Full Licence field
On 03/20/2009 08:52 AM, Lyos Gemini Norezel wrote:
Maybe it's because I'm not a lawyer, that I fail to see the
problem with
that. As long as there exists some reference to the license and a location
where it can be read, doesn't that meet the requirements of those licenses?
The short answer is not really. The more assumptions we make, the
farther we get from reality, and for the majority of FOSS licenses, we
(Fedora/Red Hat) bear the burden of informing the user of the licensing
terms of the software that we are distributing.
Here is a common scenario:
The upstream for a package changes licensing from GPL to LGPL. If we are
using a generic-licenses package, we are far less likely to notice this
change, whereas, we would immediately notice that COPYING was replaced
with COPYING.LIBS.
Wasn't there a discussion, somewhat recently, about libraries
that are
shipped with the program instead
of being stored in /lib or /usr/lib?
This is notably different. The licensing is part of our legal obligation
to our users and downstream consumers.
In addition, this comes out to about 17 MB. It is not a huge amount of
disk space, and certainly not worth the rather additional hassle it
would cause.
As it is now, each package maintainer is responsible for keeping the
license text as provided by upstream in the package, and the License tag
correct. If we were to generalize this into a central package, we'd have
to do constant auditing to be sure that the license text in the
generalized "LICENSE.rpm" exactly matched that of the package. And by
we, I mean me. Even if Red Hat Legal signed off on such an arrangement,
I'm not really thrilled by this prospect.
Now, if there were a clever way to handle this behind the scenes so that
these license files were not duplicated if they were identical, but
instead, symlinked to the license files in a generic license rpm, I
might be more interested. (If they weren't bit for bit identical, it
wouldn't be symlinked).
~spot
2:38 p.m.
New subject: Full Licence field
Tom "spot" Callaway wrote:
On 03/20/2009 08:52 AM, Lyos Gemini Norezel wrote:
> Maybe it's because I'm not a lawyer, that I fail to see the problem with
> that. As long as there exists some reference to the license and a location
> where it can be read, doesn't that meet the requirements of those licenses?
>
The short answer is not really. The more assumptions we make, the
farther we get from reality, and for the majority of FOSS licenses, we
(Fedora/Red Hat) bear the burden of informing the user of the licensing
terms of the software that we are distributing.
Here is a common scenario:
The upstream for a package changes licensing from GPL to LGPL. If we are
using a generic-licenses package, we are far less likely to notice this
change, whereas, we would immediately notice that COPYING was replaced
with COPYING.LIBS.
That would be the package maintainers responsibility, no? If a change is
that dramatic,
wouldn't the maintainer notice it right away? (I see alot of emails
about packages changing
licensing)
> Wasn't there a discussion, somewhat recently, about libraries
that are
> shipped with the program instead
> of being stored in /lib or /usr/lib?
>
This is notably different. The licensing is part of our legal obligation
to our users and downstream consumers.
I understand that, but how is a change of license file location going to
change,
or cause problems with, that obligation?
The licenses would still be available for the user to read, if they
desire, and this change
won't really inconvenience anyone.
In addition, this comes out to about 17 MB. It is not a huge amount
of
disk space, and certainly not worth the rather additional hassle it
would cause.
In reality, a change like this really should be pushed to FHS.
Standardizing the %License_File location just makes good common sense.
As it is now, each package maintainer is responsible for keeping the
license text as provided by upstream in the package, and the License tag
correct. If we were to generalize this into a central package, we'd have
to do constant auditing to be sure that the license text in the
generalized "LICENSE.rpm" exactly matched that of the package. And by
we, I mean me. Even if Red Hat Legal signed off on such an arrangement,
I'm not really thrilled by this prospect.
Now, if there were a clever way to handle this behind the scenes so that
these license files were not duplicated if they were identical, but
instead, symlinked to the license files in a generic license rpm, I
might be more interested. (If they weren't bit for bit identical, it
wouldn't be symlinked).
Isn't it possible to figure that out with a bit of bash programming?
Eg., use the 'comm' command.
"comm Compare two sorted files line by line"
and, if different, a diff could be generated to show you exactly what's
different.
Doesn't seem like much of a hassle to me.
How difficult would it be to add functionality in yum:
a.) to store the license value of each program, and
b.) to integrate a license reader for easy access/reading?
~spot
Lyos Gemini Norezel
2:43 p.m.
New subject: Full Licence field
On 03/20/2009 03:38 PM, Lyos Gemini Norezel wrote:
Isn't it possible to figure that out with a bit of bash
programming?
Eg., use the 'comm' command.
"comm Compare two sorted files line by line"
and, if different, a diff could be generated to show you exactly what's
different.
Doesn't seem like much of a hassle to me.
Are you volunteering to do the work then?
How difficult would it be to add functionality in yum:
a.) to store the license value of each program, and
b.) to integrate a license reader for easy access/reading?
I'm going to go out on a limb and say this isn't what we want. It will
just bloat the yum metadata for a rather minimal benefit.
Returning to the original problem, I'd rather see a transaction workflow
like this:
* Look at what a package has marked as a 'license file' (NOTE: RPM
doesn't really have support for this yet)
* Compare it against the set of known "Generic" licenses.
* If it is an exact match, replace it with a symlink to the Generic license.
Now, the problem is that if you do this in yum, you'll break rpm
verification of any package handled in such a way. It might be possible
to have RPM do this automagically, but I suspect they'd think it is a
monstrous hack. There are RPM devs lurking on this list, I wonder if
they will chime in.
~spot
3:06 p.m.
New subject: Full Licence field
Tom "spot" Callaway wrote:
On 03/20/2009 03:38 PM, Lyos Gemini Norezel wrote:
> Isn't it possible to figure that out with a bit of bash programming?
> Eg., use the 'comm' command.
> "comm Compare two sorted files line by line"
>
> and, if different, a diff could be generated to show you exactly what's
> different.
>
> Doesn't seem like much of a hassle to me.
>
Are you volunteering to do the work then?
I'm not much of a bash programmer (or any kind of programmer, really...
last time I could, legitimately, call myself a programmer was back in
the 8086,
6502, etc ASM days), but I'd be willing to give it a shot if there
is/would be
enough interest in such a tool.
If I had infrastructure support, I could even help setup the script to email
you the diffs when needed, provided such a script is setup on the koji
boxen.
> How difficult would it be to add functionality in yum:
> a.) to store the license value of each program, and
> b.) to integrate a license reader for easy access/reading?
>
I'm going to go out on a limb and say this isn't what we want. It will
just bloat the yum metadata for a rather minimal benefit.
Perhaps yum could store the values in a text/db file that another program
(say %license_reader) could import?
Returning to the original problem, I'd rather see a transaction
workflow
like this:
* Look at what a package has marked as a 'license file' (NOTE: RPM
doesn't really have support for this yet)
Pity. A %license (ie., like the %doc) field would be nice to have.
* Compare it against the set of known "Generic" licenses.
* If it is an exact match, replace it with a symlink to the Generic license.
Now, the problem is that if you do this in yum, you'll break rpm
verification of any package handled in such a way.
Oh? Why is that?
It might be possible to have RPM do this automagically, but I suspect
they'd think it is a
monstrous hack. There are RPM devs lurking on this list, I wonder if they will chime in.
I'd like to hear their thoughts on this, too.
Lyos Gemini Norezel
3:15 p.m.
New subject: Full Licence field
On 03/20/2009 04:06 PM, Lyos Gemini Norezel wrote:
Pity. A %license (ie., like the %doc) field would be nice to have.
Indeed. This is where I think the most interesting work needs to be
done. Once rpm knows that a %license file is a special type of %doc that
gets installed even if --excludedocs is passed, we have solved one of
the big issues for the OLPC folks.
> * Compare it against the set of known "Generic"
licenses.
> * If it is an exact match, replace it with a symlink to the Generic
> license.
>
> Now, the problem is that if you do this in yum, you'll break rpm
> verification of any package handled in such a way.
Oh? Why is that?
Well, in order for this to work, the license text has to be a real file
in the binary RPM manifest. If yum replaced that actual file with a
symlink, it will no longer match the binary RPM manifest, and rpm -V
will report that the file has been changed (which, is true, but of
little relevance in such a scenario).
~spot
4:18 a.m.
New subject: Full Licence field
On Fri, 20 Mar 2009, Tom \spot\ Callaway wrote:
On 03/20/2009 04:06 PM, Lyos Gemini Norezel wrote:
> Pity. A %license (ie., like the %doc) field would be nice to have.
Indeed. This is where I think the most interesting work needs to be
done. Once rpm knows that a %license file is a special type of %doc that
gets installed even if --excludedocs is passed, we have solved one of
the big issues for the OLPC folks.
Heh, actually rpm has had %license special file attribute since rpm 2.5.4,
it just doesn't really do much anything at all. It also doesn't play well
together with %doc, AND since the ancient copyright -> license tag change,
%license as file attribute has gotten globbered with side-effect macro
from the License: tag, so you'll have to use %%license in the %files
section.
Other than that, making --excludedocs not affect %license files is
literally a one-liner.
Making %license use in spec saner is somewhat more complicated (due to the
funny little historical issues listed above). I take it you'd like it to
behave exactly like %doc, like
%files
%doc README NEWS ChangeLog
%license COPYING
%{_bindir}/*
...which would place COPYING into the default docdir, but with the license
attribute set. Right?
- Panu -
1:21 a.m.
New subject: Full Licence field
Panu Matilainen wrote:
Making %license use in spec saner is somewhat more complicated (due
to
the funny little historical issues listed above). I take it you'd like
it to behave exactly like %doc, like
%files
%doc README NEWS ChangeLog
%license COPYING
%{_bindir}/*
...which would place COPYING into the default docdir, but with the
license attribute set. Right?
This would require rebuilding all the packages. Perhaps it is more
useful to look at a centralized system policy (overridable) that
automatically tags particular files as licenses by applying heuristics.
Eliminate the %files section instead of adding more to it.
Rahul
8:38 a.m.
New subject: Full Licence field
On 03/22/2009 05:18 AM, Panu Matilainen wrote:
Heh, actually rpm has had %license special file attribute since rpm
2.5.4, it just doesn't really do much anything at all. It also doesn't
play well together with %doc, AND since the ancient copyright -> license
tag change, %license as file attribute has gotten globbered with
side-effect macro from the License: tag, so you'll have to use %%license
in the %files section.
Other than that, making --excludedocs not affect %license files is
literally a one-liner.
Making %license use in spec saner is somewhat more complicated (due to
the funny little historical issues listed above). I take it you'd like
it to behave exactly like %doc, like
%files
%doc README NEWS ChangeLog
%license COPYING
%{_bindir}/*
...which would place COPYING into the default docdir, but with the
license attribute set. Right?
Yes, this is almost exactly what I would think would be ideal. (Yes, it
requires a rebuild, but I far prefer being able to mark the license
files rather than have some heuristic guess and get it wrong repeatedly).
The only thing I would want on top of that is what Jakub proposed
earlier in the thread:
Basically, have rpm -V ignore timestamp verification on %license files.
Then, upon install, if there is already another %license file present
with identical {md5,sha{256,512}} sum and size installed and if so, do a
byte by byte comparison and hardlink the files if they are indeed identical.
I'm not sure whether that overcomplicates the transaction or not (also,
removal would probably need to make sure we didn't leave a package
without a license text).
~spot
3:07 a.m.
New subject: Full Licence field
On Mon, 23 Mar 2009, Tom \spot\ Callaway wrote:
On 03/22/2009 05:18 AM, Panu Matilainen wrote:
> Heh, actually rpm has had %license special file attribute since rpm
> 2.5.4, it just doesn't really do much anything at all. It also doesn't
> play well together with %doc, AND since the ancient copyright -> license
> tag change, %license as file attribute has gotten globbered with
> side-effect macro from the License: tag, so you'll have to use %%license
> in the %files section.
>
> Other than that, making --excludedocs not affect %license files is
> literally a one-liner.
>
> Making %license use in spec saner is somewhat more complicated (due to
> the funny little historical issues listed above). I take it you'd like
> it to behave exactly like %doc, like
>
> %files
> %doc README NEWS ChangeLog
> %license COPYING
> %{_bindir}/*
>
> ...which would place COPYING into the default docdir, but with the
> license attribute set. Right?
Yes, this is almost exactly what I would think would be ideal.
Ok.
(Yes, it requires a rebuild, but I far prefer being able to mark the
license files rather than have some heuristic guess and get it wrong
repeatedly).
Yup, magic runtime pattern matching aint going work and aint going to
happen.
The only thing I would want on top of that is what Jakub proposed
earlier in the thread:
Basically, have rpm -V ignore timestamp verification on %license files.
Make that "have rpm -V ignore timestamp verification on files whose
hardlink count is > 1". That's reasonably in line with how rpm -V
currently treats files shared among multiple packages and makes
hardlink-on-content verification-friendly for any files, and without
making licenses a totally oddball special case in verify.
Then, upon install, if there is already another %license file
present
with identical {md5,sha{256,512}} sum and size installed and if so, do a
byte by byte comparison and hardlink the files if they are indeed identical.
I'm not sure whether that overcomplicates the transaction or not (also,
removal would probably need to make sure we didn't leave a package
without a license text).
And on every upgrade check that hardlinked files are still shareable
and if not undo hardlinks... eww. Sounds like a whole lotta trouble for
very little gain.
- Panu -
4:23 a.m.
New subject: Full Licence field
On Tue, Mar 24, 2009 at 10:07:30AM +0200, Panu Matilainen wrote:
> Basically, have rpm -V ignore timestamp verification on %license
files.
Make that "have rpm -V ignore timestamp verification on files whose
hardlink count is > 1". That's reasonably in line with how rpm -V
currently treats files shared among multiple packages and makes
hardlink-on-content verification-friendly for any files, and without
making licenses a totally oddball special case in verify.
gcc contains hardlinks (e.g. /usr/bin/{,x86_64-redhat-linux-}gcc) and for
these I'd prefer if the timestamp verification was done. Also,
if e.g. /tmp is on the same filesystem as /bin, any user can do
ln -f /bin/login /tmp/abcdefg
and avoid timestamp verification of /bin/login on subsequent rpm -V.
> Then, upon install, if there is already another %license file
present
> with identical {md5,sha{256,512}} sum and size installed and if so, do a
> byte by byte comparison and hardlink the files if they are indeed identical.
>
> I'm not sure whether that overcomplicates the transaction or not (also,
> removal would probably need to make sure we didn't leave a package
> without a license text).
A removal of a hardlink just decreases the link count, so as long as there
is at least once license file, it won't be erased.
And on every upgrade check that hardlinked files are still shareable
and
if not undo hardlinks... eww. Sounds like a whole lotta trouble for very
little gain.
I thought rpm doesn't overwrite files, but instead unpacks them under a
temporary name and renames them over. Which would mean after rename it
would be no longer a hardlink, so no need to undo hardlinks in any way.
Jakub
5:09 a.m.
New subject: Full Licence field
Jakub Jelinek wrote:
On Tue, Mar 24, 2009 at 10:07:30AM +0200, Panu Matilainen wrote:
>> Basically, have rpm -V ignore timestamp verification on %license files.
> Make that "have rpm -V ignore timestamp verification on files whose
> hardlink count is > 1". That's reasonably in line with how rpm -V
> currently treats files shared among multiple packages and makes
> hardlink-on-content verification-friendly for any files, and without
> making licenses a totally oddball special case in verify.
gcc contains hardlinks (e.g. /usr/bin/{,x86_64-redhat-linux-}gcc) and for
these I'd prefer if the timestamp verification was done.
What for?
You seem to be forgetting that files system are not read-only. Any user
has the liberty to "move/copy" around files or "touch" them.
What you really want is "identical contents", not matching timestamps.
Ralf
5:26 a.m.
New subject: Full Licence field
On Tue, 24 Mar 2009, Jakub Jelinek wrote:
On Tue, Mar 24, 2009 at 10:07:30AM +0200, Panu Matilainen wrote:
>> Basically, have rpm -V ignore timestamp verification on %license files.
>
> Make that "have rpm -V ignore timestamp verification on files whose
> hardlink count is > 1". That's reasonably in line with how rpm -V
> currently treats files shared among multiple packages and makes
> hardlink-on-content verification-friendly for any files, and without
> making licenses a totally oddball special case in verify.
gcc contains hardlinks (e.g. /usr/bin/{,x86_64-redhat-linux-}gcc) and for
these I'd prefer if the timestamp verification was done. Also,
if e.g. /tmp is on the same filesystem as /bin, any user can do
ln -f /bin/login /tmp/abcdefg
and avoid timestamp verification of /bin/login on subsequent rpm -V.
Hmm okay, any user being able to modivy rpm -V behavior is not exactly
good, although timestamp verify is pretty feeble business (considering rpm
doesnt raise conflicts on timestamp differences).
I just seriously dislike the idea of making license files somehow highly
special with different rules to everything else, when we're basically
talking about "files hardlinked outside of packaging".
>> Then, upon install, if there is already another %license file
present
>> with identical {md5,sha{256,512}} sum and size installed and if so, do a
>> byte by byte comparison and hardlink the files if they are indeed identical.
>>
>> I'm not sure whether that overcomplicates the transaction or not (also,
>> removal would probably need to make sure we didn't leave a package
>> without a license text).
A removal of a hardlink just decreases the link count, so as long as there
is at least once license file, it won't be erased.
> And on every upgrade check that hardlinked files are still shareable and
> if not undo hardlinks... eww. Sounds like a whole lotta trouble for very
> little gain.
I thought rpm doesn't overwrite files, but instead unpacks them under a
temporary name and renames them over. Which would mean after rename it
would be no longer a hardlink, so no need to undo hardlinks in any way.
Duh, indeed. I'm not thinking straight :)
- Panu -
5:50 a.m.
New subject: Full Licence field
On Tuesday 24 March 2009 10:26:23 Panu Matilainen wrote:
Hmm okay, any user being able to modivy rpm -V behavior is not
exactly
good, although timestamp verify is pretty feeble business (considering rpm
doesnt raise conflicts on timestamp differences).
If it's shared, then it should at least verify that the timestamp matches ONE OF
the packages it's shared between :o)
7:20 p.m.
New subject: Full Licence field
* Lyos Gemini Norezel [20/03/2009 22:01] :
I understand that, but how is a change of license file location going to
change, or cause problems with, that obligation?
If we had a foo package which license (the GPL) is in the
fedora-common-licenses rpm, any update to foo would require we push out an
update to fedora-common-licenses as well. If we don't, a mirror
distributing only updates would be in violation of the GPL.
Emmanuel
10:58 p.m.
New subject: Full Licence field
Tom "spot" Callaway wrote:
Now, if there were a clever way to handle this behind the scenes so
that
these license files were not duplicated if they were identical, but
instead, symlinked to the license files in a generic license rpm, I
might be more interested. (If they weren't bit for bit identical, it
wouldn't be symlinked).
/usr/sbin/hardlink -c /usr/share/doc
is pretty close to what you want.
Ralf
3:40 a.m.
New subject: Full Licence field
On Sat, Mar 21, 2009 at 04:58:11AM +0100, Ralf Corsepius wrote:
Tom "spot" Callaway wrote:
> Now, if there were a clever way to handle this behind the scenes so that
> these license files were not duplicated if they were identical, but
> instead, symlinked to the license files in a generic license rpm, I
> might be more interested. (If they weren't bit for bit identical, it
> wouldn't be symlinked).
/usr/sbin/hardlink -c /usr/share/doc
is pretty close to what you want.
Yes, but if you have %license support in rpm where all %license files
would
1) not be excluded with --excludedocs
2) for rpm -V ignore timestamp verification
rpm could just cheaply look up if there is already some %license file
with identical {md5,sha{256,512}} sum and size installed and if so, do
a byte by byte comparison and hardlink the files if they are indeed identical.
Jakub
10:09 a.m.
New subject: Full Licence field
Jakub Jelinek wrote:
On Sat, Mar 21, 2009 at 04:58:11AM +0100, Ralf Corsepius wrote:
> Tom "spot" Callaway wrote:
>> Now, if there were a clever way to handle this behind the scenes so that
>> these license files were not duplicated if they were identical, but
>> instead, symlinked to the license files in a generic license rpm, I
>> might be more interested. (If they weren't bit for bit identical, it
>> wouldn't be symlinked).
> /usr/sbin/hardlink -c /usr/share/doc
> is pretty close to what you want.
Yes, but if you have %license support in rpm where all %license files
would
1) not be excluded with --excludedocs
Right.
2) for rpm -V ignore timestamp verification
Timestamps are
irrelevant, because you want to merge files with
identical contents.
b) license-wise irrelevant - Contents matters, not timestamps.
c) Generally irrelevant in rpm.
Ralf
12:51 p.m.
New subject: Full Licence field
On Fri, 2009-03-20 at 08:52 -0400, Lyos Gemini Norezel wrote:
It seems awfully wasteful carrying a million or more copies of the
same blasted license file,
in a million or more locations in the OS.
When the hell are we going to get copy-on-write files on Linux?
http://en.wikipedia.org/wiki/Single_instance_storage
... Oh wait, MS patented it.
2:03 p.m.
New subject: Full Licence field
On Fri, Mar 20, 2009 at 12:51:10PM -0500, Callum Lerwick wrote:
On Fri, 2009-03-20 at 08:52 -0400, Lyos Gemini Norezel wrote:
> It seems awfully wasteful carrying a million or more copies of the
> same blasted license file,
> in a million or more locations in the OS.
When the hell are we going to get copy-on-write files on Linux?
http://en.wikipedia.org/wiki/Single_instance_storage
... Oh wait, MS patented it.
Wow, talk about patenting the obvious ...
Masses of prior art in the functional programming world anyhow, so I
wouldn't worry about this patent.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
5562
days inactive
5568
days old
33 comments
16 participants
participants (16)
-
Bill Crawford -
Callum Lerwick -
Chuck Anderson -
David Malcolm -
Emmanuel Seyman -
Jakub Jelinek -
Jason L Tibbitts III -
Josh Boyer -
Kevin Kofler -
Lyos Gemini Norezel -
Panu Matilainen -
Rahul Sundaram -
Ralf Corsepius -
Richard W.M. Jones -
Simon Schampijer -
Tom Callaway