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.
What is the reason the glibc-i18n package is also packaged seperately from glibc?
That package is 113mb while the whole glibc one is 136mb.
It is equal to the size of qt in current & more that double the size of firefox.
What is the reason the glibc-i18n package is also packaged seperately from glibc?
As stated in package description:
Quote:
These files go in /usr/lib/locale and /usr/share/i18n/ to provide internationalization support. You'll need this package unless you will be using US English only.
The opportunity of making a separate package (allowing people using only US English to save the additional space on disk if they wish) is stated here:
Quote:
One large and relatively independent part of glibc is the locale API and definitions of concrete locales; related to this is the subsystem dealing with various charsets and converting between them.
Conversely, there are users who do need this package but not the whole glibc.
Remember, Slackware gives you as many choices as possible and that's one of the distinctive features that many users (including me) like in it.
Last edited by Didier Spaier; 02-21-2013 at 11:23 PM.
I'd like to see kernel upgrades for Slackware stable handled by slackpkg. Following the kernel tree that the stock kernel ships with.
For example, slackware 14.0 could be able to upgrade the generic kernel to 3.2.xx whenever a new version is released. I know it's not terribly hard to do this manually but it'd be nice if it was handled by slackpkg and the kernels were compiled by someone more competent than me.
Maybe by default have this blacklisted in /etc/slackpkg/blacklist so people need to opt in?
I realize this would be a bit of work to maintain for each release across multiple architectures and slackware releases, but it would be nice..
Remember, slackpkg only knows what is part of a Slackware package tree. Everything you build yourself, you manage yourself. Slackwares-stable never has a kernel upgrade.
Remember, slackpkg only knows what is part of a Slackware package tree. Everything you build yourself, you manage yourself. Slackwares-stable never has a kernel upgrade.
Eric
This is kind of my point. It'd be nice to be able to run slackware-stable and have optional stable kernel updates handled by slackpkg.
Slackpkg doesn't know anything about kernels. These are not in the scope of this tool.
I'm not sure if I'm missing something or if I'm not doing a very good job at explaining what I'm getting at..
Slackpkg does know about kernels..
Code:
root@satellite:/# slackpkg search kernel*
Looking for kernel* in package list. Please wait... DONE
The list below shows all packages with name matching "kernel*".
[ installed ] - kernel-firmware-20120804git-noarch-1
[ installed ] - kernel-generic-3.2.29-x86_64-1
[ installed ] - kernel-huge-3.2.29-x86_64-1
[ installed ] - kernel-modules-3.2.29-x86_64-1
[ installed ] - kernel-headers-3.2.29-x86-1
[ installed ] - kernel-source-3.2.29-noarch-1
If a kernel-generic-3.2.37 package was put up into /patches I'd be able to upgrade to it using slackpkg. Correct?
This is the 'changes you'd like to see' thread, and I would like to see the ability to receive (optional) updates to the kernel using proper Slackware package management.
Please don't get me wrong on this, I am not trying to start a big discussion.
I would like the *option* because when I want to install something, I want to install it. That's all. If it has dependencies, so be it - install them too.
For those who want more control, they wouldn't pick the *optional* 'do it all' approach.
I'll give 'slapt-get' a look-see.
I'm mostly using slackpkg and sbopkg for package management, but recently, I gave slapt-get a try on Xfce-based desktops. I installed spkg, slapt-get and slapt-src from Salix and - starting from a Slackware base system with X11 and Xfce, configured the Salix repos and installed all needed apps step by step. Works nice, and adds some comfort. Only thing I did was blacklist sysvinit-scripts and lilo, so they wouldn't get crushed by Salix versions after an upgrade.
Here's the resulting Slackware-plus-Salix desktop:
root@satellite:/# slackpkg search kernel*
Looking for kernel* in package list. Please wait... DONE
The list below shows all packages with name matching "kernel*".
Slackpkg knows about packages, but it does know nothing about the purpose of the contents. These packages have the word "kernel" in their name, but that's just convention. You can find other distributions, that call them "linux" or something different.
Quote:
If a kernel-generic-3.2.37 package was put up into /patches I'd be able to upgrade to it using slackpkg. Correct?
You can upgrade it using upgradepkg or you can let slackpkg execute upgradepkg for you. That's all about it.
Quote:
This is the 'changes you'd like to see' thread, and I would like to see the ability to receive (optional) updates to the kernel using proper Slackware package management.
You receive kernel updates via patches, if there is a severe reason, like a major bug or a security issue. Otherwise there is no need for upgrades, because Slackware -stable is called "stable" for a reason.
If you want prepackaged kernel upgrades just for fun you have build them yourself or mandate someone to do it for you.
If a kernel-generic-3.2.37 package was put up into /patches I'd be able to upgrade to it using slackpkg. Correct?
You saw my line "Slackwares-stable never has a kernel upgrade"?
In Slackware history, there was exactly one case where a newer kernel was added to the patches directory after a stable release. This was for Slackware 12.2 and it addresses a critical local root exploit.
Code:
+--------------------------+
Tue Aug 18 14:35:23 CDT 2009
patches/packages/linux-2.6.27.31/:
Added new kernels and kernel packages for Linux 2.6.27.31 to address
a bug in proto_ops structures which could allow a user to use the
kernel sendpage operation to execute arbitrary code in page zero.
This could allow local users to gain escalated privileges.
This flaw was discovered by Tavis Ormandy and Julien Tinnes of the
Google Security Team.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2692
In addition, these kernels change CONFIG_DEFAULT_MMAP_MIN_ADDR kernel
config option value to 4096, which should prevent the execution of
arbitrary code by future NULL dereference bugs that might be found in
the kernel. If you are compiling your own kernel, please check this
option in your .config. If it is set to =0, you may wish to edit it
to 4096 (or some other value > 0) and then reconfigure, or the kernel
will not have default protection against zero page attacks from
userspace.
(* Security fix *)
patches/packages/kernel-mmap_min_addr-4096-noarch-1.tgz:
This package adds an init script to edit /etc/sysctl.conf, adding
this config option:
vm.mmap_min_addr = 4096
This will configure the kernel to disallow mmap() to userspace of any
page lower than 4096, preventing privilege escalation by CVE-2009-2692.
This is a hot fix package and will take effect immediately upon
installation on any system running a kernel that supports configurable
/proc/sys/vm/mmap_min_addr (kernel 2.6.23 or newer).
(* Security fix *)
+--------------------------+
Don't count on things like this happening more often though.
You saw my line "Slackwares-stable never has a kernel upgrade"?
In Slackware history, there was exactly one case where a newer kernel was added to the patches directory after a stable release. This was for Slackware 12.2 and it addresses a critical local root exploit.
It has happened more than once. There were actually two kernel security patches issued for Slackware 8.1. However, most of the time there were security related updates for the kernel over Slackware's history, Slackware was more of a rolling release and didn't have a /patches directory, so it's easy to miss those.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
