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.
[...]
src2pkg is meant to fill a gap between official SlackBuilds (and those from SlackBuilds.org) for people who want or need to compile other software for their system but don't have the skills to write a build script or don't wish to spend so much time writing and debugging a script for a build. [...]
[...]But here's a point I'd like to see a solution in future versions of Slackware: OOo has an automatic updating mechanism, like Mozilla Firefox, Thunderbird, Seamonkey and an increasing number of other applications. The auto-update functionality only works well, if the directory hierarchy and the locations of the files installed are exactly where the original vendor expects them to be, and when the application has write access to these places. Which is usually not the case.
That raises the question, how to deal with such packages. Eg, the auto-updater of Firefox is non-functional on Slackware. Wouldn't it be better switched off, then, by default, in Slackware? The answer is, of course, no, as this would also de-activate the plug-in finder/installer, too (at least, that's my understanding).
To be honest, I have really no good idea what could be done, here. I just see an increasing need for having a more or less sophisticated solution approach here, as the number of packages available, and included in Slackware as standard, is continuosly growing. Probably, this is an issue for Linux in general, not only for Slackware, but other major distros already found their own ways to solve this. Eg, SuSE/Novell have their own OOo distribution as part of their Linux distribution. This is certainly not the recommended way for Slackware, but a solution of some kind is needed, I think.
gargamel
Having an active auto-updater for Firefox, Thunderbird, and OOo on Slackware seems to go against what I see as the usual Slackware way. The administrator should be the only one doing the updating so I'm fine with simply using updatepkg (though I wrote a short script to also correctly move/copy over Firefox plugins automatically. I suppose you could write a script/cron job that checks for a new version and downloads it, creates a package, and then updates the package. This of course wouldn't be using Firefox's (or T-bird's, etc) auto-update feature, but it would get the job done.
I used to desire a command line option for Firefox that would run the auto-update feature and I started working on an extension to do just that, but it is easy to update it yourself so I decided I didn't need it.
So, in short, I wouldn't want any auto-update features active on my Slackware. If I miss that sort of thing I can always hop onto Ubuntu or Windows...
Having an active auto-updater for Firefox, Thunderbird, and OOo on Slackware seems to go against what I see as the usual Slackware way. The administrator should be the only one doing the updating so I'm fine with simply using updatepkg (though I wrote a short script to also correctly move/copy over Firefox plugins automatically.
[...]
So, in short, I wouldn't want any auto-update features active on my Slackware. If I miss that sort of thing I can always hop onto Ubuntu or Windows...
That's ONE way of thinking about this topic, and, as you say, it is in line with the Slackware philosophy, as it is straight forward and simple. However, as a consequence, auto-updaters should be de-activated by default in Slackware packages. Which they are not, currently.
That's ONE way of thinking about this topic, and, as you say, it is in line with the Slackware philosophy, as it is straight forward and simple. However, as a consequence, auto-updaters should be de-activated by default in Slackware packages. Which they are not, currently.
How do the auto-updaters affect anything at all for you? I've not seen a single message from any of them in any of my installations, so what's different?
From what I've heard from other users, the auto-update notifications only happen if the application is run as root. I don't want to ignite another flame fest about the pros and cons of running as root, but yeah, you get the idea.
How do the auto-updaters affect anything at all for you? I've not seen a single message from any of them in any of my installations, so what's different?
From what I've heard from other users, the auto-update notifications only happen if the application is run as root.
This is true for me as well, so I don't understand why it should be turned off by default for Slackware.
[...]I hope you all know freebsd handbook. One of the greatest manuals ever (and not only for freebsd, but for whole *bsd oses and more). I wish Slackware could have smth similar. Because Slackware is the most Unix like system there (please don't argue with me), it should have such type of handbook just because lots of things written here also applies to other distros most often without problems. Once RedHat was thought as the classic and the only one reliable GNU/Linux (I still have some of those old manuals), but these times are over. Constant patching doesn't increase system compatibility.[...]
Why? don't you know tldp, do you?
if Slackware is for nerds... why slack users don't used to RTFM?
However, as a consequence, auto-updaters should be de-activated by default in Slackware packages. Which they are not, currently.
Is it even possible to completely disable automatic updates in FireFox and Thunerbird from the package maintainer's side? Keep in mind that currently they are not built from source, so it isn't as if the updater can be excluded in the build (though I have no idea if that is even a compile-time option).
As others have said, unless you have permissions to overwrite /usr/lib/firefox(thunderbird), the updater won't do anything; which seems about the safest approach. If you want the automatic updates, then install the application to your home folder, which should re-enable the updater; if you don't want the updater, then just use the packages as-is.
This seems in line with classic Unix philosophy, where software installed to /usr is maintained by the administrator (and package manager), and software under /home is handled by the individual user.
How do the auto-updaters affect anything at all for you? I've not seen a single message from any of them in any of my installations, so what's different?
From what I've heard from other users, the auto-update notifications only happen if the application is run as root. I don't want to ignite another flame fest about the pros and cons of running as root, but yeah, you get the idea.
True for Firefox and Thunderbird, so the Slackware approach is, as usual, consistent, here. 8-)
Yet, that doesn't answer the question, if this is the optimum solution in the long run, although I can live well with it. And, of course, the same question can be asked for third-party packages and Slackbuilds. ;-)
Example: With all installations of OpenOffice.org on Slackware so far I had to switch off the auto-updater, because it detected a new version, asked me if I would install it, and then failed, of course, when I answered yes. I expected it to fail, but an average end-user will expect that his software is being upgraded.
But, actually, it is not a big problem, and there's absolutely no potential for a flamewar in this.
If you're going to offer constructive criticism please edit/proofread before posting a message.
Probably he's still ...testing...?
Sorry, couldn't resist. ;-)
gargamel
EDIT: For "political correctness" I should make it clear, that this wasn't meant as an offense, at all, and that I don't have any resentment against testing, whatsoever. It was just playing with words.
Speaking of RTFM, maybe I should recommend this program that I put together a year or so ago: http://distro.ibiblio.org/pub/linux/...6.1-i486-1.tgz
That's a nice little GUI program for searching man pages by category and includes a viewer -no joke!
The program is a hacked combination of two programs -gman and coolman, but I just couldn't resist naming it that way. No one has ever heard of the program and yet it gets recommended by name all the time...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Funny stuff, man.
