LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 05-26-2008, 12:44 PM   #16
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Original Poster
Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534

Quote:
I guess I'm strange -- I don't feel the need (or want) to install an app that does way more than what I need just to do something a simple script does just as well (and takes up less room).
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.
 
Old 09-17-2008, 06:08 AM   #17
harryhaller
Member
 
Registered: Sep 2004
Distribution: Slackware-14.0
Posts: 452

Rep: Reputation: Disabled
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.
 
Old 09-17-2008, 06:29 AM   #18
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,311

Rep: Reputation: Disabled
Quote:
Originally Posted by harryhaller View Post
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
 
Old 09-17-2008, 06:49 AM   #19
harryhaller
Member
 
Registered: Sep 2004
Distribution: Slackware-14.0
Posts: 452

Rep: Reputation: Disabled
Quote:
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.
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.
 
Old 09-17-2008, 07:56 AM   #20
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,311

Rep: Reputation: Disabled
Quote:
Originally Posted by harryhaller View Post
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.
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
Code:
OUTPUT=${OUTPUT:-/tmp}	# Drop the package in /tmp
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.

Quote:
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.
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
 
Old 09-17-2008, 08:13 AM   #21
harryhaller
Member
 
Registered: Sep 2004
Distribution: Slackware-14.0
Posts: 452

Rep: Reputation: Disabled
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.

Last edited by harryhaller; 09-17-2008 at 08:19 AM.
 
Old 09-17-2008, 08:18 AM   #22
Bruce Hill
HCL Maintainer
 
Registered: Jun 2003
Location: Tupelo, MS
Distribution: Gentoo
Posts: 6,926

Rep: Reputation: 124Reputation: 124
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!
 
Old 09-17-2008, 08:36 AM   #23
harryhaller
Member
 
Registered: Sep 2004
Distribution: Slackware-14.0
Posts: 452

Rep: Reputation: Disabled
Quote:
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.
Sorry, I am clearly getting confused. That is good news then. I will edit the SB script in future to go to /usr/local.

Quote:
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.
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

Last edited by harryhaller; 09-17-2008 at 08:40 AM.
 
Old 09-17-2008, 08:48 AM   #24
harryhaller
Member
 
Registered: Sep 2004
Distribution: Slackware-14.0
Posts: 452

Rep: Reputation: Disabled
Quote:
I would like to add that Eric (Alien Bob) has created Alien's SlackBuild Toolkit,
Thanks Eric and Bruce - that's neat!
 
Old 09-17-2008, 09:19 AM   #25
piete
Member
 
Registered: Apr 2005
Location: Havant, Hampshire, UK
Distribution: Slamd64, Slackware, PS2Linux
Posts: 465

Rep: Reputation: 44
Quote:
I would like install/removepkg to respect the /usr/local prefix
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.

Last edited by piete; 09-17-2008 at 09:20 AM.
 
Old 09-17-2008, 10:33 AM   #26
harryhaller
Member
 
Registered: Sep 2004
Distribution: Slackware-14.0
Posts: 452

Rep: Reputation: Disabled
Quote:
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.
That is precisely the aim. I.e. in /usr/local. But why "mirrored"?

Quote:
On a clean install, copy the log back and magically pkgtool remembers how to remove that package and is therefore managing it again!
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.
 
Old 09-17-2008, 10:43 AM   #27
keefaz
Senior Member
 
Registered: Mar 2004
Distribution: Slackware
Posts: 4,614

Rep: Reputation: 136Reputation: 136
Quote:
Originally Posted by harryhaller View Post
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
 
Old 09-17-2008, 12:09 PM   #28
GazL
Senior Member
 
Registered: May 2008
Posts: 3,440

Rep: Reputation: 959Reputation: 959Reputation: 959Reputation: 959Reputation: 959Reputation: 959Reputation: 959Reputation: 959
Quote:
Originally Posted by keefaz View Post
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.
 
Old 09-17-2008, 01:33 PM   #29
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Original Poster
Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
Quote:
It seems to me that the best thing is to install all non-stock packages in /usr/local.
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.

Quote:
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.
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.
 
Old 09-17-2008, 04:18 PM   #30
Bruce Hill
HCL Maintainer
 
Registered: Jun 2003
Location: Tupelo, MS
Distribution: Gentoo
Posts: 6,926

Rep: Reputation: 124Reputation: 124
Quote:
Originally Posted by Alien Bob View Post
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.

Eric
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.
 
  


Reply

Tags
packages, slackpkg, slackware


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Listing of packages installed on system borgibo Linux - Newbie 4 06-16-2008 03:42 PM
listing the installed Packages nmansour Linux - Newbie 4 10-28-2007 02:16 PM
Make slackpkg prefer /extra over /slackware when listing packages to update rignes Slackware 1 06-02-2007 06:00 PM
Listing of packages installed on system kushalkoolwal Debian 12 06-22-2006 02:59 AM
Listing installed packages in Gentoo ? Builder Linux - Distributions 1 07-08-2004 05:09 PM


All times are GMT -5. The time now is 01:23 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration