What features/changes would you like to see in future Slackware?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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 :-)
AFAIK db is used by python, ruby, perl and web related stuff like apache etc, so its a pretty important package.
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.
Quote:
Originally Posted by rworkman
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 :-)
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".
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? :-)
Debian is switching to EGLIBC and the reasons they list are all good. Should Slackware do the same?
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.