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

Re: Visualboy Advance question.



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: pgphIA0uzulT4.pgp
Description: PGP signature


Reply to: