On Thu, May 06, 1999 at 05:42:45PM -0700, Joseph Carter wrote:
> 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!)
Perhaps the FSF should be mailed so they can add this to the GNU Task
List, unless someone here is interested in starting a project. I guess
either gnu@gnu.org would be the appropriate address to contact.
> > It's nice to see that this sort of discussion points out areas where free
> > software is lacking.
> 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.
...and repeat. Which is what I did.
I found that this method claims that libc6 is `affected' by the removal
of truetype fonts, which is clearly completely wrong. I found that
not only did this include suggests-dependencies, but also included
conflict-dependencies. I am *completely* unconvinced by this method.
> 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,
In the long term, perhaps. If we implement this tomorrow, Suggests:
would stay *exactly* as they are. As would Conflicts:.
In other words this whole discussion *does* *not* *affect* a number
of those packages. How many? God knows. If you really want it to be
considered for discussion *you* need to work it out though.
> 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.
``Hey, look, there are too many packages listed, sure, but I'll bet there's
really not enough!''
What?
I can assure you, repeating gives you a completely exhaustive list of
packages that have any relationship with freetype. I know this because
it lists *every* package.
But any sort of relationship at all isn't even vaguely interesting for
this discussion.
FWIW, pkg-order has some options to only care about Depends: and
Recommends:. No, I have no idea how to use it.
> 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.
Ummm. No. They wouldn't.
What would happen to them?
They'd... well... sit there. Their control files wouldn't need to get
changed (we haven't done anything about Suggests: yet, because Enhances:
doesn't exist), they wouldn't get moved to contrib, they wouldn't have to have a
new entry in README.Debian.
Would the changelog entry be "Reuploaded in mourning for the removal of
freetype from main. No changes." ?
Exactly _how_ would they be affected?
And exactly how is this even *vaguely* relevant to this discussion,
except as a way of avoiding the topic at hand?
> Does it mean some of the packages shouldn't be related to freetype?
> Most certainly.
No. It doesn't.
> Does it mean that a number of packages would be affected
> by such a change in a single case? Absolutely.
No. It doesn't.
You have yet to demonstrate either of these claims.
apt-cache does not do what you seem to think it does.
> > 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.
If you don't have to have a BIOS to use Lilo (successfully. I don't mean
`use' in the sense, "hey! it changed my hard drive!", or "hey! I got an
error message! woo!") then it doesn't have anything to do with this
discussion.
Furthermore, if there is a free BIOS, or a free BIOS emulator out there
-- one that actually exists as code on a disk, not as a figment of your
imagination, I guess I have to add -- again, Lilo doesn't have anything
to do with this discussion. This is indeed good enough to put TiK into
main, no matter what.
> 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...)
If someone writes a server for TiK with netcat and bash and perl,
and releases it under DFSG-free terms, then yes, that's perfectly good
enough to make TiK part of the official Debian system. If no one has yet,
then it shouldn't be part of that system yet.
Similarly, if someone writes a replacement xforms library in just, say, C,
and releases it under DFSG-free terms, that's enough to move any libxforms
based programs into the official Debian system. But, if no one has yet,
then xforms based programs should stay out of the official Debian system
until someone does.
> So the argument applies or it doesn't. It can't apply to one and not the
> other.
And yes, in an ideal world we'd have free BIOSes, and anything that
only worked with non-free ones would be taken out of the official
Debian system. Unfortunately, we're not in an ideal world yet, and we're
not at the point where we can do this.
Similarly, in an ideal world, we'd have free CPU designs, and we'd be
able to finally demote i386 to a second-class architecture.
But this isn't an ideal world, at least, not yet, and we do have to make
compromises. At the moment, we've drawn the line at software we install
on your system -- we haven't even gone so far as to replace some of the
Windows software you use to do an install (I'm particularly thinking of
things like defrag).
We're not advocating erasing the line in the sand. Stuff like LILO and
i386 binaries are going to stay for a while, and be exempted because
although they depend on non-free components, there just isn't an alternative
for standard PC components and firmware yet. When there is, perhaps we'll
move the line again, or erase it entirely.
But that's not now. Now, we're at the point where we can comfortably
ignore any non-free software that wants to be put on our own machines. I
also assert that we're also at the point where we can can comfortably
ignore software that's only purpose is to interact with non-free software.
Sure, you, personally, might want to use ICQ, or TiK, or whatever; just
like I, personally, want to use jdk and netscape. That's fine. Debian
even supports us doing that, by giving us non-free and contrib. But
just because they're convenient and useful does not mean they should be
an official part of the Debian system.
> I think Manoj was considering writing a simple skeletal tik server in
> netcat as a proof of concept.
And if he releases it with a DFSG license then yes, that's good enough
to get TiK in main without questions asked. If he doesn't, well, then
we've got two proprietry servers for a free client. Gee, great.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``Smart, sexy, single. Pick any two (you can't have all three).''
-- RFC 1925, paraphrased: a guide to networking in the '90s
Attachment:
pgpiECToBceir.pgp
Description: PGP signature