Are these essential packages in Slack? Perhaps the size of the release
could be pared a little bit by excluding them?
I may be a rare case though. How do you guys handle these particularly
easy to get programs? Do you have multiple users on many of your Slack
boxen? The kind that use these sort of desktop apps?
--
DESTINATION UNKNOWN
I find it even easier to keep Firefox upgraded by having it installed from
the package provided by Slackware. That way firefox gets upgraded if
needed every time I install the latest Slackware patches. I have written a
simple Makefile which installs patch packages as well as some other
updates which I distribute as slackware packages:
-8<-----------------------
PACKAGES = $(wildcard *.tgz)
LOG_FILES = $(PACKAGES:%.tgz=/var/log/packages/%)
all: $(LOG_FILES)
/var/log/packages/%: %.tgz
upgradepkg --install-new $<
-8<-----------------------
The Makefile is in a directory with symbolic links to the latest patch
files and updated custom packages. Some day I might improve the Makefile
to first check that it is run on the right version of Slackware. I have
different machines with different versions of Slackware and Slamd64 which
calls these Makefiles from a cron job. However if I would test to call one
of these Makefiles manually and I would be standing in a directory for
another version of Slackware it would really mess things up on that
machine.
> Are these essential packages in Slack? Perhaps the size of the release
> could be pared a little bit by excluding them?
IMHO Firefox belongs to the standard Slackware packages. Moving firefox to
/extra or completely remove it would probably make a lot of people miss
it.
> I may be a rare case though. How do you guys handle these particularly
> easy to get programs?
See above.
> Do you have multiple users on many of your Slack boxen? The kind that
> use these sort of desktop apps?
Yes, my boxes have many users and they use browsers and other desktop
apps. Using the approach with Firefox and other programs in $HOME/bin
would put administrative tasks on every user and also require a lot of
space on the NFS servers with home directories.
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost
I guess I'd answer with another question, which is, why do you feel
the need to constantly upgrade? Complete Slack upgrades come at least
once per year and I have yet to ever see a need to upgrade a between
Slack release of anything. I've even skipped an odd release now and
then. In fact, it's now become clear linux has matured enough that
newer releases of many programs are not only unnecessary, but
sometimes downright unwelcome, as recently revealed by the huge
disapproval of KDE 4.2.
I did discover a bug in Seamonkey that prevented the installation of
the latest NoScript, which wouldn't be ironed out till the 2.0 release
of Seamonkey, a compelling reason to upgrade. Turns out using a tad
bit older version of NoScript worked just fine.
I guess some ppl just gotta be on that cutting edge. Me? Only with
my shaving razor. ;)
nb
I just upgrade FF/TB whenever Pat releases a security fix package. Easy
to know when that happens by subscribing the the "Slack-security" mailing
list. As for OO.o, I install it from slackbuilds.org, and rarely bother
updating it between Slack releases. If I did want to, it's simply a
matter of re-doing the Slackbuild and upgrading the package.
I do not have multiple users, but the other benefit of doing it this way
is (obviously) that each user doesn't have to manage his own updates,
especially if they are not able to do such things...
--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me".
"Bother!" said Pooh, as he garotted another passing Liberal.
Usenet Improvement Project: http://twovoyagers.com/improve-usenet.org/
> I do not have multiple users, but the other benefit of doing it this way
> is (obviously) that each user doesn't have to manage his own updates,
> especially if they are not able to do such things...
...or if one just likes to use multiple user accts, which I do.
That's always been one of the attractions of *nix for me. It's easy
to customize different accts to one's preferences. I've got my online
acct, business acct, ebay acct, graphics acct, etc, each with
different browser prefs, desktops, dirs, files, etc. Installing
software globally makes for easy maint, while individual accts allows
more granular customization. It's similar to using multiple
workspaces, yet in some cases, handier and easier to manage.
nb
Good point. I haven't done that kind of thing, but it sounds like
perhaps I should look into it. Cool.
Seamonkey-2.0 has already been released. And, IMHO, it looks ugly! :-)
--
Mikhail
> Seamonkey-2.0 has already been released. And, IMHO, it looks ugly! :-)
Yeah... I noticed a couple weeks ago. As I said, no pressing reason
to upgrade at this point. I'll wait for next rev of Slack.
nb
Support for the latest scripting geegaws and such is my only excuse. The
fact that firefox complains if it can't upgrade itself I find annoying
as well.
> once per year and I have yet to ever see a need to upgrade a between
> Slack release of anything. I've even skipped an odd release now and
> then. In fact, it's now become clear linux has matured enough that
> newer releases of many programs are not only unnecessary, but
> sometimes downright unwelcome, as recently revealed by the huge
> disapproval of KDE 4.2.
I missed 10.0 and 11.0, but not 12.0 or 13.0. I'm using KDE 4.2 with no
real hatred towards it. I dont feel the need to keep everything on my
machine up to date (I've never run -current), just Firefox and OO,
really.
> I did discover a bug in Seamonkey that prevented the installation of
> the latest NoScript, which wouldn't be ironed out till the 2.0 release
> of Seamonkey, a compelling reason to upgrade. Turns out using a tad
> bit older version of NoScript worked just fine.
>
> I guess some ppl just gotta be on that cutting edge. Me? Only with
> my shaving razor. ;)
>
> nb
--
Many people feel that they deserve some kind of
recognition for all the bad things they haven't done.
> fact that firefox complains if it can't upgrade itself I find annoying
> as well.
You should never see it more than once. There's a "do not show this
notice again" check box.
nb
As well as "do not press this button again" . . .
:-)
--
Steveski
do you use multiple X servers or do you just do a lot of xauth or
xhosting or do you logout/login frequently ?
> do you use multiple X servers....
yep
"Online account" - you mean the one for downloading porn.
- Kurt
Yeah, but then it's not updated and the neurotic portion of my mind
(which is a fairly sizeable portion) goes around in circles "it's not
updated. There's new stuff there you dont have. Hey idiot! It'll only
take a minute gogetitgogetitgogetit." Annoying, that.
--
The greatest griefs are those we cause ourselves.
-- Sophocles
nooo
he has a porn account you know
it's an important task :D
Finally said and done I now have the following improved Makefile:
-8<-----------------------
PACKAGES = $(wildcard *.tgz)
LOG_FILES = $(PACKAGES:%.tgz=/var/log/packages/%)
VERSION_FILE = $(wildcard sla*-version)
all: Check_Version $(LOG_FILES)
/var/log/packages/%: %.tgz
upgradepkg --install-new --reinstall $<
Check_Version:
diff $(VERSION_FILE) /etc/$(VERSION_FILE)
-8<-----------------------
The Makefile is in the same directory as symbolic links to the latest
patch packages and other packages containing updated settings for my
machines. In this directory I now also have a copy of
/etc/slackware-version or /etc/slamd64-version. This file prevents the
Makefile from accidentally installing packages on the wrong version of
Slackware when run manually.
The Makefile is called daily (or rather nightly) by a file
/etc/cron.daily/slack_update with contents something like the following:
-8<-----------------------
#!/bin/sh
( cd /auto/slack120/updates ; make ) > /var/log/slack_update
-8<-----------------------
I hope that someone else will find these routines useful.