The quake2 engine is a gaming engine. Lots of libraries in our current source are the same sort of things, and at one time did not have a game based on them. Did they go into contrib? No. If they had a game based on them that was non-free, would we put them in contrib? Probably not, because they are libraries as opposed to binaries.

Not so with the quake2 engine. However, just because it is a binary executable engine does not make it any different than a development library in terms of game development. Advertise the thing as a gaming engine, not as a game. Call the package "quake2-engine", and then once we get some, we will have "cool-game" Depend: quake2-engine. The fact is, that the quake2-engine does not depend on anything to perform what it was made for, and that is to be a gaming engine. The data is the game, and requires the engine.

The distinction between contrib and main is not whether it is *possible* to create something free which the contrib software would be useful for; it's really whether there *is* such a thing.

If the only practical use of the engine is to run non-free levels from id, then it belongs in contrib. If someone has levels (that at are all fun--that is, which are real games) which the engine works with, then it belongs (along with those levels) in main.

The issues keeping quake 2 out of main, granting Ben's insistence that it can be looked at as an engine for games, are:

* As an engine for games, it is woefully lacking in documentation. Programming languages have at least one of a spec, sample code, a body of existing code, or something to read to learn them, while this "engine" does not.

* Nobody has actually come forward and volenteered to put this in main and give it the level of mantainance software in main deserves. If it were in main, they would really be obligated to be able to tell users some way it can be used, whether that is pointing them as a game that uses it, or at some documentation for writing one or at a free level editor or whatever. But if all the maintainer can do is point the user at data files you buy on CD, it makes a mockery of it being in main.

So in summary we may have actually excluded a package from being in main because it lacks sufficient documentation (nice precedent ;-), and this can all be changed by one maintainer with sufficient chutzpah to upload it to main and deal with the consequences.

Anyway, g++-3.0 seems to be completely broken on sparc. int main(){return(0);} gets a bus error. So I guess I'll just don't build on sparc. Unless I get a really easy way to fix this (butit seems to me to be something unsopported in g++-2.95).

Of course it is broken. It is _not_ supported on sparc, other than to make it available to users. _I_ do not want anything built on sparc that doesn't use the default compiler (except in cases such as libc6-sparc64 where we obviously have to use the 64-bit capable gcc-3.0 compiler).

It should be policy that programs are required to use the default compiler on an arch. You create serious overhead on arch maintainence when you ignore that.

While I don't disagree with such a policy in general, I think that exceptions should be allowed.

On ia64, there really isn't a super-strong code generation engine available. The default gcc (2.96!) is a bit behind in bugfixes, and gcc 3.x, although much better at generating ia64 code, has other weaknesses. We try to build everything with gcc 2.96 as much as possible, but in some cases, gcc 3.0 is required to get code that works. In those cases, we haven't seen anything wrong with debian/rules hackery to set CC=gcc-3.0 and so on, and Build-Depend on gcc-3.0 [ia64].

Is this something you object to? I understand how you might object on sparc, since gcc 2.95 has supported sparc for a long time now. But on newer architectures, we may not have the luxury to mandate a single gcc version.

And if you object, could you suggest a solution? Some of the packages affected are very large and complex and "fix the problem in the source of your package" would, most likely, involve quite a bit of work. I suspect in a few of those cases that the only feasible response would be to remove the package from the architecture, which seems a shame if building with a different compiler would fix the problem.

For some time now there has been an increasing trend in people that I know who use debian. It is the view that debian is becoming increasingly "old"/outdated, and that developers either a: dont' have the time to properly maintain packages, or just don't care. Which the case is here I don't know. I'm not intimate with a lot of developers. However, this has been the same view that has been slowly dawning over me for a while now.

I see an increasing trend of two critical problems in the way debian operates. #1 package age. Let me talk about this one first. There has been a relatively (year or two) explosion in the package count. As this package count has gone up, packages that I have used for years and that used to work well have falen into a sad state or disrepair.

CDRToaster hasn't been updated on the homepage since Jan 2001 at ver 1.12. Obviously this package is DEAD. 8-P I'm sad to see it go as I am on many usefull programs such as this one.

However, that leaves a problem. I've been told by several developers that "it's an upstream problem. send them a patch and when they include it we will update". Wel, that argument doesn't work in increasingly common cases like this. At this point, it is now (IMHO) the debian packagers problem. If they are unwilling or unable to fix it, then the package should be marked as "BAD" or "dead-upstream" as a warning to the user that they should pick a different utility like this one to use.

What I see happening is this. The package count has increased proportionatly to the ammount of bugs per package. This is giving debian a bad name. This is driving users away. Eventualy if this continues, debian WILL die or be a nice distribution only diehard fans of it's ideals will use.

Now a little history for you to understand my view of why this prevaling attitude is annoying to say the least, and has me up in arms over it so to speak. When I signed on to distribute debian, it was rock solid. Packages were only marginaly out of date. People loved it. Users loved it. Debian people trash talked redhat daily over it's bugs.(not all debian folk, just the more vocal and publicly seen ones). I have slowly stoped recomending it as the number of people that tried it because of me has shifted from mostly "nice distro. thanks" to "this is buggy, and out of date. thanks a lot. >:( ".

Oh god no. Please no. Inflating bug severeties just makes it harder to do releases; if there's a problem with normal bugs being ignored (and, IMO, there is), it needs to be addressed directly, not worked around by filing everything as important or higher.

Hrm. At least tell me that I'm misreading this, and what you meant to say was `` "higher quality" than "average" '' or something.