Not strange.

One task, one tool. Your script fits the bill.

I'm still using your original script along with my minor modifications. I run the script hourly through cron and save the diff file to two different physical locations --- on my primary drive and my secondary drive. Both diff files get backed up daily and weekly. Should I ever have to rebuild bare metal (gulp!) I should have access to a list of non stock packages --- somewhere.

Eric's rsync scripts, which I modified slightly to my needs, also satisfies the idea of one task, one tool. I run the scripts daily through cron and maintain my patches and current trees. Simple and straightforward.

We live in a big world where there is almost always more than one way to solve a problem. Simple one-task scripts work for some, more complicated scripts like slackpkg work for others. To me that is one of the advantages of free/libre software and Slackware --- very little is shoved down our throats. We each get to choose our path and comfort zone.

Thanks again for your efforts on this thread.

Good thread!

It seems to me that the best thing is to install all non-stock packages in /usr/local.

Apparently installpkg and removepkg allow this if you add -root /usr/local to the command line - I haven't yet tried it though.

No, that is not what the -root option is for! The directory "-root" is pointing to must always be the root of a Slackware filesystem. Either your own system's root (/) or that of another that you have mounted for maintenance, or to work in using chroot, or if you are the Slackware installer (which uses "-root /mnt" to install your system).

If a package was compiled to use /usr instead of /usr/local then there is no way you can install it to /usr/local and expect it to work. The only option is to recompile it using a prefix of /usr/local instead of /usr .

Eric

Well - a good job I posted that, because I clearly misunderstood the man page. Thanks Bob.

If I compile a SlackBuild package I cannot change the configure options since they relate to the location of where the package is to be created - by default /tmp.

Either installpkg or SlackBuild etc. should provide an option to specify a different target directory area.

I've started only recently using SB and the other packages - before I would always compile myself - to /usr/local of course. That's messy because it's difficult keeping track of the programs and their related components.

Now, I am now regretting having installed packages to the stock core system - especially because of the problems when installing a new system or updating the old system - as this thread has revealed.

If a package is not part of the distro - it should be installed to /usr/local.

I suppose I'll have to hack my own version of SlackBuild.

Nothing forces you to use /tmp as the output location (where the packages are created). If you look at any SlackBuild on the SBo site, they have a line
Which means you can change that to any other directory.
And: this location has nothing to do with the software's "configure" command parameters. The "configure --prefix=/usr" just means that the resulting software (not the Slackware package) is going to use /usr and the directories below that (bin, share, man, ...). Please do not confuse the two.

If you install software as a Slackware package it does not matter (with respect to manageability) whether it is compiled for using /usr or /usr/local - you can easily remove any package from your system using the removepkg command.
And exactly for that reason, I would advise to create only packages that install themselves into "prefix=/usr". It does make the compilation of other software that depends on it, easier afterwards.

And any software that you manually compile and install (./configure && make && make install) will by default install itself with a "prefix=/usr/local" which is good because it enables you to quickly wipe anything you ever compiled - by going onto /usr/local and deleting the stuff you find there. You will be certain that there is no proper Slackware package (official or 3rd party) that installed itself to /usr/local . You keep packages and locally-compiled software nicely apart this way.

Eric

I just ran installpkg -root $HOME/local as a non-root user.

It couldn't update /var/log etc. nor could it run ldconfig, of course, because of the permissons, but it did install correctly to my home directory.

Running it as root, it installed the package, but still had problems writing to /var - this time without complaining - because there is not record of the installation there.

Hence removepkg failed since there was no record of the installation.

This is just for info, to see what happens if one uses the "root" option as I though it could be used.

I would like to add that Eric (Alien Bob) has created Alien's SlackBuild Toolkit,
an online SlackBuild script generator that you can use as a template for making
your own Slackpacks. It is serving me very well.

Thanks, Eric!

Sorry, I am clearly getting confused. That is good news then. I will edit the SB script in future to go to /usr/local.

This is true of updates, but not of clean installs.

Up until now all software I had installed myself (/usr/local) would simply be remounted after a clean install. In /usr, I would have to re-install all the packages again.

Even if I changed the configure options within the SB script - the install log would be in /var - not in /usr/local/var - and hence be missing in a clean install.

I would like install/removepkg to respect the /usr/local prefix and open a separate /var/log under /usr/local thus providing a clean separation between the stock system and the local additions, since the local subdirectories persist after a clean installation.

The two parts should be kept separate since their origins and fate are separate.

So at the moment, by changing the SB script I could install to /usr/local - but would lose all records of it and the ability to use removepkg after a clean install.

Thanks again for clearing up the misunderstandings that crept into my head, Eric - I was working late last night - I must have been more tired than I realised

Thanks Eric and Bruce - that's neat!

It doesn't understand the /usr/local prefix to respect it. If you do a clean install of SuSE or Debian or Ubuntu or Redhat do you expect, having installed 3rd party packages previously, to be able to now remove those 3rd party packages?

No. Because they're registered to the package manager which you've since wiped along with the rest of the "core" install.

If you register something with the package manager you're saying "This package? It's now core to me. Look after it for me." If you don't want it managed that way then do it the old fashioned way:

./configure --prefix=/usr/local && make && make install

You cannot have a core system with tools and expect those tools to exist anywhere outside of that system (slackware + pkgtool). It doesn't matter how you slice it, a clean install will (as far as the package manager is concerned) remove records of anything the system considers core, and since you've told the system these new packages are also core ... poof.

What you can do is look at it another way: the only thing that is required for the pkgtool to understand about a package is the log in /var/log/packages/<packagename>. So if you can ensure a package that you build does not encroach on territory outside of /usr/local (/etc for example), you can mirror your 3rd party (non-core/unmanaged/etc) install logs elsewhere. On a clean install, copy the log back and magically pkgtool remembers how to remove that package and is therefore managing it again!

What you may wish to look into are things called tagfiles, with which you can build your own installable catergories, so reinstalling previously built packages doesn't become a burden. This is a much better solution than the above, imo. 30 seconds on google brought me this:

http://www.bilbos-stekkie.com/tagger/tagfiles.html

I daresay you'll discover a whole stack more information with a bit of patience and the right key words.

Finally, here are some ideas for you to chew on that should help future posts. Crucially, the only difference between a "slackbuild package" and an "installpkg package" is that slackbuild is a 3rd party site so the available packages there are not part of core slack release, unlike the latter.

slackbuild: script that generates a (Slackware) package from given source code and associated patches
package: gzipped tar containing (usually) binary files and an install script
pkgtools: collection of (Slackware) package management tools including:
- installpkg
- removepkg
- makepkg

Best regards,
- Piete.

That is precisely the aim. I.e. in /usr/local. But why "mirrored"?

Or have the package respect/look in /usr/local as well.

This is why I was quite excited by the "root" option of install/removepkg since I thought that with that option, it would understand that it was relocating itself from the root directory to the /usr/local with /usr/local being the prefix for all locations that it used (except ld.conf etc.).

By clean install, I mean, of course, a clean of install of the same distro (as opposed to an update) - hence I can expect the package tools to "re-appear" in the new installation. A migration to another distro is another matter.

But your suggestions regarding the tag files are a possible alternative - nevertheless, the idea of /usr/local being self sufficient regarding the components included in the package together with the installation logs is, imho, the best and cleanest way.

Clearly, it's best to stick to updates. Unfortunately if you skip a release or two - as I and others did going from 10.1 to 12.1 - one is forced to do a clean install.

I upgraded my Slackware system from 10.1 to 12.1 with a clean install
But I have a separate /home partition and a /home/build directory where I put kernel sources and all extra softwares sources with the corresponding packages and slackbuild scripts. This way I can always do a clean install and reinstall the extra softwares I added to Slackware system, either with the tgz packages or I rebuild them with the slackbuild scripts

That's good advice. I do exactly the same.

That might be an idea for people who zealously control their own box. For third-party packagers, such as the great people at slackbuilds.org, I think the best presumption is install in /usr. Many end-users do not maintain /usr/local in a separate partition, therefore compiling a package for that location provides no benefit over installing into /usr. Third-party packagers cannot and should not presume a separate /usr/local file system. Besides, the /usr/local file system is supposed to be reserved for end-users only.

People who regularly get their hands dirty with their system easily can modify the build scripts to /usr/local. For myself, I prefer to maintain my separate /usr/local partition and file system. I consider third-party packages from slackbuilds.org and slacky.eu to be system (core) software rather than personal software. Therefore I prefer to have those packages installed in /usr.

I change the location in every build script I download because I have /tmp mounted non-executable. I also maintain a separate build area for all of my software and I use a separate tmp location within that area.

I haven't finished my first cup of coffee this morning, so maybe I'm not
reading some posts after this one correctly. But this is very important,
IMO, and should be considered. Unless you don't plan on compiling any
other packages -- such as Woodsman's 64 non-stock packages.