Nicotine too!

No, not cocaine! :D Ok guys, stop spam.

seriously: I'd like to see more software on slackware, and I mean *.tgz.

Not really a feature request, just a question.
Does anyone know why db is so outdated in Slackware? And why there are two available versions?
I am talking about l/db42 & l/db44.

This won't outright answer the questions, but it might help you to arrive at one :-)
1. Every db version is incompatible with every other db version. No, I'm not exaggerating. Therefore, anything that uses it has to be recompiled, and there's possibility that the data will be corrupted due to the incompatibilities present.
2. Everything works just fine with what we have, right? :-)

I knew about no.1 i am asking cause db 4.4 is years old (ChangeLog last updated on 01/12/2006), 4.2 is significantly older (ChangeLog last updated on 2003/12/12 9:00:00), and if there was a will to be updated there would probably be some signs of that all this time.
AFAIK db is used by python, ruby, perl and web related stuff like apache etc, so its a pretty important package.

Understood, but the main point was this: is there something that won't build/work properly due to our old(er) version of bdb? That's a serious question - I'm not being an asshole :-)

Could you clarify a bit?
 

Are you sure it is "used by"? I always thought that python/ruby/perl have db bindings that allow them to access db data, but I never heard of any dependency on db. Apache can run applications that use db but I never heard that Apache is dependent on it. More so, I always thought that Apache requires a special module to run apps that use db safe. Thus, it looks like "can be used with", not "used by". If the above is not the fact, please explain since this is important in any db talk.
The db packages describe themselves as "This package should be installed if compatibility is needed with databases created with the Berkeley DB version 4.2.x." If this is correct, everything should build/work properly with what we have until a data file created with version 4.3, 4.5, 4.6, or 4.7 is hit. So, the answer to the question may be "nothing", but this is meaningless in the context of package selection. Apps that actually use db may compile fine but reduce functionality if an older version of db is offered, like "no 4.7 - no heterogeneous replication".

Why not drop both 42 and 44 and add 4.6 and 4.7?

Next release slogan?
Slackware 13: Unlucky for those who don't use it.

Case sensitive uniformity.

Hi,
OR!

Slackware® 13: Lucky for those that do use it!

Debian is switching to EGLIBC and the reasons they list are all good. Should Slackware do the same?

Although i never install it, i noticed that the package l/glibc-i18n contains files which are also present in l/glibc.
Is there any reason for that? This is in -current BTW, didnt check 12.2.

I suspect that's because the i18n stuff changes often enough that it's too much trouble to try and figure out the dupes and then remove them, only to have to do that work again with the next release. None of the dupes hurt anything, and our package manager doesn't try to be too "smart" and refuse to install packages with duplicate files, so why bother? :-)

Isn't it because the main glibc package contains all the files included in all of the individual glibc-** packages?

Debian is going to switch to EGlibc because they are not happy with the work/character of Ulrich Drepper. It seems that this guy sits in an ivory tower and Glibc is currently not developed in an open source style. This operation is thought as a shot across the bows...

On Topic:
I'd like to see xine compiled with support for matroska and i'd like to see the mkvtoolnix package. MKV is the best video container available and it is fully open source. I can't understand why this is currently not supported but the crappy avi is.


cu