On Tue, 22 Jun 2004 09:55:25 +1000 Matthew Palmer wrote:
> > Well, I thought that useless software is maybe not worth to
> > distribute at all. You seem to imply that a free, but useless
> > package must be placed in contrib rather than in main...
>
> I implied nothing of the sort.
I'm sorry if I misunderstood you.
Just to avoid that this happen again in the future: where should a free
emulator with no free data to process (and thus useless in a
free-software only environment) go? I thought you said contrib...
>
> > > Let me ask you this: if there was an image viewer, which only
> > > viewed one format of images, and there were no images out there in
> > > that format, would you want to see that in Debian? What if there
> > > were images in that format, but in order to get them you'd have to
> > > break copyright law?
> >
> > Cannot someone create some free image in that format in the near
> > future? Why should Debian wait for one such image to *be packaged*
> > before moving the viewer from contrib to main?
>
> Please quote back to me the part where I said that such content needed
> to be packaged in order for us to consider it. *Nowhere* did I make
> that claim. I'm only talking about whether such content exists *at*
> *all*.
Ah.
The thread started from a question by Dan Korostelev who asked why
visualboyadvance is in contrib.
The first answer was by Benjamin Cutler who said:
| The same reason fceu was in contrib until 'efp' was packaged, because
| the requires at least one piece of software that's not in Debian in
| order to be useful. Find a good free rom, package it, and VBA can move
| into main just like fceu did. zsnes remains in contrib for the same
| reason.
Note the "package it" part.
Since you didn't stated that, in your opinion, the packaging requirement
was to be dropped, I thought that you agreed with Benjamin and were just
taking extreme examples when you were talking about cases with *no* free
data at all.
I now realize that I was wrong in this assumption: I stand corrected.
> For most of these emulators, the only source of 'data' for
> them is ripping lock-in games from their cartridges. Whilst that
> isn't necessarily breaking the law, it is DFSG-non-free, and if the
> emulator is significantly impaired without one of them, I believe it
> falls under SC#1.
Well, now I think I see what you mean (also in light of the below
clarification about what the Policy says about the Depends meaning...).
[...]
> > I've always interpreted the "require" as "depend on", in the sense
> > of the "Depends" field.
> > And I've always saw the dependences as not related to usefulness (a
> > program cannot depend on its input data).
> >
> > Of course, I may be wrong...
>
> I think you are. To re-quote policy, "The Depends field should be
> used if the depended-on package is required for the depending package
> to provide a significant amount of functionality." Usefulness is a
> function of functionality. No functionality, no utility (usefulness).
> For an emulator,
> no ROM, no functionality, no utility. If there's no free ROM, then we
> go through the chain again, ending at "not in main".
So be it...
--
| GnuPG Key ID = DD6DFCF4 | You're compiling a program
Francesco | Key fingerprint = | and, all of a sudden, boom!
Poli | C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
| 31B5 78F4 279B DD6D FCF4 | version 1.8.0
Attachment:
pgp5FLPzdf_60.pgp
Description: PGP signature