[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Control fields for installer packages, and other vrms thoughts

On Tue, Aug 28, 2001 at 02:53:25AM +0100, Colin Watson wrote:
> It would be useful to have some way to automatically find contrib
> installer packages for non-free software: in particular, it would mean
> that vrms could start picking them up. Would it be reasonable to ask the
> maintainers of such packages to include a field like 'Installer-Section:
> non-free/foo' in their control files, similar to the field that
> identifies some meta-packages? This would be very easy to implement, as
> policy C.2.2.1 (from the old packaging manual) provides a way to include
> such fields without special support from dpkg.

I'm not sure if I like your implementation much.  I don't have a better
solution though.

> While I'm thinking about vrms, it's been a long-standing wishlist to
> have vrms provide more verbose information about the packages it lists.
> Unfortunately, we don't have mechanically parseable copyright files, and
> it's probably unreasonable to expect the vrms maintainer to keep up with
> every non-free package in Debian. Here's an idea which would distribute
> the load:

It would be nice if packages could provide more information for vrms.
Example from my own system:

acroread                  Adobe Acrobat Reader: Portable Document Format
gimp1.2-nonfree           GIF and TIFF support for the GNU Image
lha                       lzh archiver
nvidia-glx                nVIDIA binary XFree86 4.x driver
nvidia-kernel-2.4.3-ac12  nVIDIA binary kernel module for Linux 2.4.3-ac12
unarj                     arj unarchive utility
unrar                     Unarchiver for .rar files

I really would like to see vrms tell me about contrib packages as well at
the least - from my own system:


I really think vrms should list contrib packages somehow.  Maybe as a
seperate list?

> We could recommend that non-free packages install a file of the form
> /usr/share/vrms/<package>.

Hence the reason for the examples above - gimp1.2-nonfree has no problems
with its license, except that it includes LZW and Unisys might have to
hunt you down over it in countries such as the US..  (I'm in the US, just
goes to show how much regard I have for the Unisys patent or any other
software patent for that matter, eh?)  It would be very nice to have a
command like vrms-info <package> that tells you more about why a package
is non-free and maybe if we're real lucky if it has any dependencies, etc.

Of course I don't know of anything but such a line to include, so maybe
one file per non-free or contrib package would be a waste of inoeds.
Another system could be a good idea, even if it takes a little more work.
Diskspace is cheap but it's still not free.

> That file could either be a short description
> of why the licence is non-free, or a symlink to another file. If it's a
> symlink, the target is of course displayed instead, so we can have a few
> descriptions of particular licences or styles of licence in vrms itself.
> For example:
>   /usr/share/vrms/Not-For-Profit

This seems like a bad idea.  I'd rather the vrms file provided by the
package list the sections of the DFSG it is incompatible with in some
machine parsable format which can then spit out nice messages saying that
we believe section 1 of the DFSG is not met by this license.  We should be
wary of crossing the line between saying why we didn't put it in main and
trying to interpret the license for people.  The latter could get us into
some big troubles.

>     For more information, see:
>       http://www.gnu.org/philosophy/categories.html#semi-freeSoftware
> This is kind of the opposite of /usr/share/common-licenses. :) Less
> well-known licences or categories of licence can just include the
> opinion of the package maintainer or whatever.

I'd complain about the FSF link, but we are talking about a program named
vrms here, so..  =)

> Are these good ideas? I did the last NMU of vrms, so I'm willing to
> write the (relatively small amount of) code necessary to implement these
> and ask for permission for further non-maintainer uploads.

I'd like to see larger changes to the code that make it give you more
information, like the section of the package, etc.  At least I'd like the
option to see that info.  And I do think 

Joseph Carter <knghtbrd@debian.org>                 Free software developer

> > But IANAL, of course.
> IANAL either.  My son is, but if I asked him I might get an answer I
> wouldn't want to hear.

"Here's my invoice." ?  =D

Attachment: pgpyoBE_pDF57.pgp
Description: PGP signature

Reply to: