Re: Bug#30739: When a tiny part of a package uses non-free libraries
At Tue, 15 Dec 1998 14:40:06 -0500,
Brian Mays <brian@debian.org> wrote:
> > pcmcia-cs only suggests non-free/libforms0.88, however it contains
> > /usr/X11R6/bin/cardinfo, which DEPENDS non-free/libforms0.88. I think
> > it's DFSG violation.
>
> While I appreciate your attention to details and pedantic advice, I
> would like to point out that cardinfo is not required for PCMCIA
> support. It is merely a cute little X application that monitors the
> PCMCIA slots and allows the user to interactively send commands to
> cardmgr, the PCMCIA card management daemon. This is why pcmcia-cs only
> "suggests" libforms and does not "depend" on or "recommend" it.
> According to current Debian policy, a package must be placed in contrib
> if it "depends" on or "recommends" a non-free package. It does not
> require packages that "suggest" a non-free package to be moved to
> contrib.
I've heard PPxP packages are refused to put in main, because it contains
ppxp-forms which depends libforms0.88. Takuro Kitame, PPxP maintainer,
had the trouble to build ppxp packages to be separated due to its dependency
problems (only fppxp, included in ppxp-forms, depends on non-free/libforms0.88)
However, ppxp-forms package contains only fppxp, which is merely a cute little
X application that monitors the PPP connections and allows the user to
interactively to control the ppxpd, like cardinfo of pcmcia-cs.
So, if ppxp maintainer had built a package which contains all
binary of ppxp in it and "suggests" libforms0.88,
with the same manner of pcmcia-cs, then would ppxp be allowed in main?
If it is in main, I think it's very strange judgments.
If it still is not allowed in main, I think it's very unfair judgments,
because it's the same situation of pcmcia-cs.
My point is that I'd like to know what is the standard of DFSG judgments.
If package say "suggests non-free" but some binary in it depends non-free,
is it in main (like pcmcia-cs) or not?
In the discussion on #debian, someone said that ppxp is non-free, because
it contains the source depending non-free (libforms0.88). But if we
take this judgments, pcmcia-cs should go in contrib because it contains
cardmgr/cardinfo.c which depends non-free (libforms0.88).
I think this judgments is too pedantic.
> > I think cardinfo should go in contrib, cardinfo should be removed or
> > someone should develop DFSG free utility like cardinfo.
>
> First, I would like to say that your third alternative is definitely
> the best. Are there any volunteers to port cardinfo to use a DFSG-free
> library? If given such a utility, I'll place it in the pcmcia-cs
> package and dump the libforms-based cardinfo.
Yes, I agree with you. Third alternative, replacing with DFSG free utility,
is the best solution.
> Otherwise, I don't think that anything needs to be changed, however.
> Splitting cardinfo into its own package is a bad case of excessive
> package fragmentation, in my opinion. Cardinfo comes from the same
> upstream sources as the rest of the PCMCIA utilities, it is a small
> program, and it will never be used without having the rest of the
> PCMCIA support programs installed. Therefore, I don't think that it
> merits its own package. Having an extra 24k of support data for a 12k
> program seems a bit ridiculous to me.
So do you think there is no problem that ppxp packages also is in main?
The size of fppxp (which is the binary depends libforms0.88) is only 32k.
--
Fumitoshi UKAI / Debian JP Project
Reply to: