Re: Control fields for installer packages, and other vrms thoughts
On Mon, Aug 27, 2001 at 11:45:49PM -0700, Joseph Carter wrote:
> 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.
It's not wonderful, I admit. Maybe it's an artifact of the way we have
installers in contrib in the first place (I see the reasoning, but it
does mean that our stubs in the packaging system for software we can't
redistribute at all look "better" from some perspectives than, say,
non-commercial use only licences).
> I really would like to see vrms tell me about contrib packages as well at
> the least - from my own system:
>
> nscache
> nvidia-glx-src
> nvidia-kernel-src
> quake-data-shareware
> quake-data-stub
> realplayer
>
> I really think vrms should list contrib packages somehow. Maybe as a
> seperate list?
Well, not all contrib packages are necessarily the province of vrms,
although now that non-crypto etc. packages that depend on non-US go into
non-US rather than contrib it's substantially more true than it used to
be. Is anybody using the "require ... packages which are not in our
archive at all" clause for something other than non-free software?
> 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.
Tracking reverse dependencies (see vrms' README.Debian) would probably
be more useful. But yes. As a last result it could dump the copyright
file to a pager, although I was looking for more of a summary.
> 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.
Perhaps a system like tasksel's, i.e. a file kept in CVS so that any
developer can update the list of explanations, might work?
> 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.
That could even go back into the status file - Fails-DFSG: 1, 5, 6?
(I'm just throwing out ideas here, not all of them might work.)
> 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.
Fair point, especially in certain countries.
> > 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
What would the rest of that sentence have been?
Thanks for the comments,
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: