Build systems usually default to /usr/local/ and that is often checked before other paths.

1 members found this post helpful.

I started using Slackware around 1994-5... I have always found it to be a very educational experience... although lately I find it is getting to be a bit annoying when it comes to package managers. Slackware needs a unified package manager. I have had enough issues with slackpkg for some reason lately than the whole time I have used Slackware, but I suppose that's a discussion that could never come to a good conclusion. Linux as a whole needs to adopt a standard and stick to it with regards to the package management issue.

Linux is a Kernel; it shouldn't have a unified package manager. Slackware is an OS; each OS should determine how package management is handled.

3 members found this post helpful.

Agreed. I like the package management system of Slackware.

1 members found this post helpful.

I'm actually glad to see this stated since I have no intention of ever automating anything about package management, but then I'm probably something of a Luddite.. but my base systems never break. I prefer that.

1 members found this post helpful.

I just use installpkg/upgradepkg/removepkg... that's my package management right there (and they take wildcards). I still use ftp to get packages from -current mirrors too.

That's not something I want to change. I don't even like that /var/log/packages was moved and replaced with a symlink. Dinosaur, here

6 members found this post helpful.

Ditto!

That's the thing about choice in Linux: you'll never get all maintainers of distro's to agree to that.
RPM was an attempt to create a universal package format/program and although quite a few distro's are using it (not just the Red Hat derived ones), even the update manager on top of rpm differs in those distro's (from yum, now being replaced by dnf), through zypper/yast (SUSE) to urpmi and rpmdrake for mageia.
According to wikipedia
(from en.wikipedia.org/wiki/RPM_Package_Manager)

I like the fact that there’s lots of choice in the open source ecosystem. I like the way Slackware manages packages, but, I support choice. Diversity is a good thing.

1 members found this post helpful.

Easier now??? BWAHAHAHAHAHAHAHAAA!!!!

I started my 25-year love affair with Slack around Christmas 1995, with v.3.0. My employer at the time used SunOS, and several co-workers had begun raving about this new open-source OS that a young CS student in Finland had written, and posted on USENET. The idea of having my own UNIX workstation at home got me stoked, so I borrowed a friend's Walnut Creek CD, and, not owning a CD writer, spent a Saturday burning 120 3.5" floppies.

The guinea pig was a 386SX/33, with 4MB of RAM, a Trident SVGA card, and a USR Sportster 28.8 card....500MB hard drive.
The only docs at the time were apropos and the manpages...Matt Welsh and Lars Werzenius hadn't written their awesome books yet, so there was no FM to RTFM.
I heartily recommend the following entertainments for anyone with masochistic tendencies..
1- Using XF86config, Xconfigurator, and Xvidtune to set up a monitor with unknown clock and sync frequencies.
2- Writing a dip script for connecting to an ISP who's helpdesk has no idea what their RADIUS connect stanzas are.
3- Figuring out why LILO keeps writing the bootstrap code offset by 2 from where it should be.
4- Sussing out why dip keeps putting a lockfile on ttyS0, whenever it's called.

Configuring MWM and FVWM, I won't mention...I still get reflux thinking about it.

It took several evenings of beer and frustration, but lo and behold, I was eventually rewarded with...

Welcome to wintermute (192.168.10.100)
You have mail.
{root@wintermute}/home2/root%>_

On my last Slack-14.2 install, I went from ext4fs install to first boot in less than 15 minutes.

Over the last 25 years, Patrick, Alien Bob, and the rest of the Slack team have done an outstanding job in shepherding Slackware into it's niche as THE Linux distro for serious users, who want a rock-stable,easily mastered, hackable UNIX-like OS.

Slackness has triumphed!!
Hail Bob.

1 members found this post helpful.

Or write your own.
I still like to handle .new files manually.

My scripts only work with a local mirror before anyone asks, but IMO it's the best way to do it, especially when following current.

2 members found this post helpful.

Now that was indeed pretty cool bsdaemon, but you could've gotten away with just 96 floppies if you'd formatted to 1.8Megs

What is the significance of this?

There's a game called Digital: A Love Story which is about hacking BBSs, and the hostname in that game is 'wintermoot' [a slight variation]. So what does it refer to?

I wrote my own scripts too, including one to update the local mirror: slget (SLackware GET, which uses "wget" to get anything on the website that is newer than on my local mirror. And then just using upgradepkg to selectively update those packages I do want updated in my system.
The (probably) difference with your case is that I keep a mirror of all Slackware releases (including architecture variants) - no -current yet (too quick-moving target).
For instance "slget 14.2" will get all newer packages for 14.2 32- AND 64-bit versions, but only from the "patches/packages" directories (the rest is in the iso's anyway, which I got images of too).
It would be easy to extend the scheme to -current, but at the moment it is not really needed, I will as soon as 15.0 has been released.

Yes, I only mirror the bits I'm interested in. Just current64, minus kde/kdei which I exclude from the rsync.

Basically, my script keeps the installed system in sync with the locally available packages in a priority ordered list of local directories. At the moment, I'm only using two:
/srv/slackware/local/packages64/
/srv/slackware/slackware64-current/slackware64/

If I were following stable, then .../patches/packages would be in the list before the main slackware64 package dir.

It's a very simple approach: no metadata to worry about, and it doesn't read 'ChangeLog' in order to identify packages.

1 members found this post helpful.