On Thu, May 06, 1999 at 05:01:27PM +1000, Anthony Towns wrote: > First note: There aren't any free TrueType editors? That's not good. There > don't even seem to be any projects to create one. That's not good either.
None that I know of. Correcting this would be good though, anybody else interested? (I *heart* my TTF!) > It's nice to see that this sort of discussion points out areas where free > software is lacking. > > > afterstep, aview, cgoban, cjk-latex, dox, enlightenment, > > enlightenment-docs, enlightenment-nosound, > > enlightenment-theme-brushedmetal, enlightenment-theme-clean, > > enlightenment-theme-cleanbig, enlightenment-theme-estepclassic, > > enlightenment-theme-estepnew, enlightenment-theme-ice, > > enlightenment-theme-shinymetal, freetype-tools, freetype1, > > freetype1-dev, freetype2, freetype2-dev, freewrl, fvwmconf, gem, > > gltt-bin, gltt2, gltt2-dev, hatman, html2ps, imagemagick, imgsizer, > > libgfont, libgfont-dev, libmagick4-dev, libmagick4-lzw-dev, > > libmagick4g, libmagick4g-lzw, mgp, moonlight, mozilla, netscape3, > > netscape4, pcd2html, pd, perlmagick, php3, php3-cgi, php3-cgi-gd, > > php3-gd, pike-image, roxen, webmagick, xfstt, xmbdfed, xmorph, yudit > > Yay. Woo. Now, how did you come up with that? > > I tried using apt-cache to come up with a list like this [0], and came up > with chains like: [..] > > Which doesn't seem particularly convincing to me. But perhaps you had > a better method. I can't tell if you don't tell me what it is, though. [EMAIL PROTECTED]:~$ apt-cache showpkg freetype2 Package: freetype2 Versions: 1.2-6(/var/state/apt/lists/saens.debian.org_debian_dists_potato_main_binary-i386_Packages)(/var/lib/dpkg/status), Reverse Depends: yudit,freetype2 xmbdfed,freetype2 php3-gd,freetype2 php3-cgi-gd,freetype2 perlmagick,freetype2 moonlight,freetype2 mgp,freetype2 libmagick4g,freetype2 imagemagick,freetype2 hatman,freetype2 gltt2,freetype2 gltt-bin,freetype2 gem,freetype2 freetype2-dev,freetype2 freetype1,freetype2 freetype-tools,freetype2 enlightenment-nosound,freetype2 enlightenment,freetype2 dox,freetype2 Dependencies: 1.2-6 - libc6 (2 2.1) freetype2-dev (0 (null)) freetype-tools (0 (null)) freetype (0 (null)) freetype0 (0 (null)) freetype1 (0 (null)) Provides: 1.2-6 - Reverse Provides: All right, now you take all of those things in the revrse depends and you run them through apt-get showpkg <the whole list of packages reverse depended, space seperated> and catch the the output. Strip that down to just the reverse depends contents and sort. Remove everything after the , and get rid of duplicate entries. Paragraph format the result. You have the list above. Note the list above isn't totally fair because I'm sure there are many Suggests: entries. However we did decide that such Suggests: are bad and should go away, and if the package really has nothing to do with freetype or packages using it as could be argued to "invalidate" my list, the packages still have superfluous relationships that should be considered bugs. => > > WHEE! 55 packages! And I bet if I ran those through to find out what > > depends on them the list WILL get longer. IIRC james said the number of > > packages affected doesn't matter to him at all. Well it matters to me, > > especially what packages are affected. I'm guessing it matters to other > > people too. mozilla, roxen, imagemagick, perlmagick, afterstep, E... Oh > > yes, I believe this matters. > > Yup. Trace it through 15 rounds and libc6 `depends' on freetype. Not for > particularly useful values of `depends', though. > > > In all fairness a number of those ARE almost certainly Suggests: lines > > and could be ignored or removed. > > This includes the second example you list, aview. > > And in any case, you completely mischaracterised the result of the "Should > main packages suggest contrib/non-free packages?" discussion. The result > was not "No, they mustn't, such things must be thrown out of main", it was > "Well, yeah, it's a pain, let's implement an Enhances: dependency and > replace main Suggests contrib/non-free with contrib/non-free Enhances > main". > > Suggests are /completely/ irrelevant for this discussion. Indeed. However I wasn't able to easily get a list of just those packages which have Recommends and stronger dependencies on TTF packages. It's probably not an exhaustive list of those packages even. The packages that suggest it ARE relevant because they would be affected by the decision to remove FreeType and other TTF-handling packages from main. Does this mean the packages should be removed from main? Not at all. Does it mean some of the packages shouldn't be related to freetype? Most certainly. Does it mean that a number of packages would be affected by such a change in a single case? Absolutely. That was the point of the exercise. > > The whole point is simple: How far do we want to go? Are we going put > > lilo in contrib because of the non-free BIOS in your PC next? It's been > > argued by a few people (myself included) on irc that removing tik because > > of the server it uses is the same thing as removing lilo because of the > > BIOS it uses... > > Let's see. LILO uses BIOS code to do its job, does it -- like it > calls BIOS functions. Gee. That's like library calls. Hey! Lilo links > to non-free code! It *already* shouldn't be in main, what a double > standard *that* is. It's okay to link to BIOSes, but it's not okay to > link libxforms?! Bunch of hypocrites. Not required to build lilo and possibly not required to use lilo. POSSIBLY not required. I believe it's possible to use lilo without int13h calls. And it was argued that with the x86 emulator that has free BIOS, it definitely is possible. That's fine, but that's the same argument james said wasn't good enough for tik (ie that even though just about nobody is going to, one can use netcat and bash or perl or whatever else as a server for tik...) So the argument applies or it doesn't. It can't apply to one and not the other. With the possibility to use lilo with something stored on a ROM chip (was suggested on irc, I don't know if lilo can or not yet) it may become a moot point---other than that it's still not going to be used by anybody in the real world that way. => > No, no one's suggesting people should be concerned about every possible > dependency on non-free software, only the ones where we believe avoiding > the dependency on non-free software is a useful and possible thing to do. > > If you want to prove that it *is* impossible, don't keep on exaggerating > your case. We're not suggesting throwing Lilo out, and the 55 packages > you list aren't equally affected if Truetype software were to be dumped > into contrib. They are affected though. And the comparison to how LILO can be used freely is directly comparitive to how tik can be used freely. > > It's also been argued there's a free BIOS for an x86 emulator out there, > > but almost nobody is going to use lilo with an x86 emulator---they'll use > > it with their x86 box! Just like almost nobody would use anything but > > AOL's non-free server for tik... > > Almost nobody? No, _nobody at all_. And not by choice, but because there > just isn't an alternative. > > If there's an alternative to non-free BIOSes, even if it's not one that > people choose to use with any frequency then you've just defeated your > own argument: if there was an alternative to non-free servers for TiK, > whether people want to use it or not, then that's *fine* for main. I think Manoj was considering writing a simple skeletal tik server in netcat as a proof of concept. -- Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer PGP: E8D68481E3A8BB77 8EE22996C9445FBE The Source Comes First! ------------------------------------------------------------------------- <Culus> there is 150 meg in the /tmp dir! DEAR LORD
pgpusqqeon2S9.pgp
Description: PGP signature
