src2pkg: problem with docs, man pages etc. [solved]
 

When creating a package that should be installed to /usr/local,
src2pkg places the documents into /usr/doc (man,info,etc) instead of /usr/local/doc (man,info, etc).

01-pre_process treats installations to /usr/local specially or better said - all documents are hardwired to go into /usr/doc (and /usr/man, /usr/info etc).

I have changed it so that all documents go into $PRE_FIX/doc (and $PRE_FIX/man, $PRE_FIX/info etc).

There is a bit of coding in 01-pre_process as follows:
I've commented out this bit of coding.

In 11-create_docs, all docs are hardwired to go into /usr/doc.

I've changed this to /$PRE_FIX/doc.

Since it is possible to have different versions of the same program on the system for different users - some with /usr/local in their path and some not, man, info etc. from one version of a program could be clobbered by the documentation from the other version.

For the doc directory, it is clearer and tidier if that documentation is stored similarly under the same diectory prefix as that of the programs etc. to which it refers.

Further, I think that src2pkg - which is proving itself to be excellent (!!!) should be under control of the user and not overide the configure options etc. chosen by the user.

Since I would like it to be possible for users to be able to install tgz packages into their home directory, the issues involved becomes clearer. Clearly, before I can enable installs to the users home directory, I'll have to have an ersatz installpkg for non-root installs.

Those are the only problems I've had with src2pkg and otherwise the program is super:)

My only concern about making packages that install to /usr/local is that if the package name is the same as a currently installed package in /usr, you break the package install log by installing that.

Clearly if you're confident in your naming scheme, that ceases being a problem :)

Installing a package that contains files in /home/<user> seems unnecessary to me because it will get logged under /var/log (as previously discussed). To install programs into places like that, I would be inclined to compile and install into somewhere like /home/<user>/programs or similar *without* the package manager, which could look very much like /usr and /usr/local.

Editting .bash_profile to include something like the following from /etc/profile:

And then adding appropriate profile scripts to build the path of those unconventional packages will at least include the binaries in the users path.

The more I look at the problems, the more I think I can see what you're trying to do. You want to be able to allow users to package and install their own software, and to register that software locally such that it doesn't interfere with any of your core system (or registration). Please correct me if I'm wrong.

The best (imho) solution to that is to (as a user) build packages as an appdir. Gilbert will, I'm positive, come up with some interesting ideas too, but here's some reading in the mean time: http://roscidus.com/desktop/AppDirs

Best regards,
- Piete

Well, I have more than ideas about AppDirs -I have a template system for creating AppDirs pretty easily. but first, let me address the thing with the docs.

The bit you (harryhaller) commented out in 01-pre_process is supposed to turn off corrections. The corrections are supposed to force all esssential docs into the 'official' Slackware docs dir under /usr/doc. src2pkg also makes sure the docs have a version number even if they are installed without it. But, packages that are using /usr/local or /opt are supposed to not get their docs moved. I'll have to have a check and make sure that is working correctly. src2pkg used to force all docs and mans into /usr excpet for when using /opt, but I had already had (only) one user who really wanted to create packages with prefix /usr/local and have everything there.
I've been conservative with implementing that because it really goes outside of 'normal' packaging guidelines. The is even more true for having the package database in /usr/local/var/log -this is clearly not right because pkgtool wil not show packages there.

You can also put this in the global or user conf file:
## Package corrections preferences
! [[ $CORRECT_NAMES ]] && CORRECT_NAMES="NO"
! [[ $CORRECT_MANS ]] && CORRECT_MANS="NO"
! [[ $CORRECT_DOCS ]] && CORRECT_DOCS="NO"

src2pkg tries to follow the status quo regarding Slackware-compatible directory layout and packaging conventions. The corrections are all about seeing common cases where an installation doesn't have things right, and then fixing it without fuss. You can disable these things individually with a couple of entries in your src2pkg.conf file.

I haven't been more on top of changing this because I try to discourage making packages with /usr/local as prefix, but I have been thinking for awhile about changing all these related routines to be able to handle different compatibiblity schemes. src2pkg now tries to force lsb-compliant doc, man and info paths into Slack-compliant. But I do plan to work it out so you could do the opposite if you want, just ba changing a variable in your conf file.

Anyway, if piete guessed right, you might want to look at my AppDir kit here:
http://distro.ibiblio.org/pub/linux/...uilder-0.4.tbz

The AppBuilder is an archive with a template for an AppDir, just unpack the archive and change the name to whatever you like. Then, unpack your sources inside there and create a link 'src' to the uncompressed sources. Then, edit the top of the script to put the name of the executable. Then, you can compile, install locally(insie the same AppDir directory) and run the program by executing The AppRun script in the topleverl of the AppDir: 'bash ./AppRun'. You can then create a link to the AppRun script anywhere you like.
For instance, I keep all my AppDirs in /usr/apps. An example is /usr/apps/ATerm
I have a link:
/usr/apps/ATerm/AppRun --> /usr/bin/aterm
which puts the application in my regular users' PATH.

This may be closer to what you want. It's not nearly so advanced as src2pkg, but it still makes it pretty easy to create appdirs -even with extra features.

I think you won't find it hard to modify installpkg/removepkg/pkgtool so that they work for stuff installed under /usr/local. And in fact, you should be able to use src2pkg to use /usr/local/var/log/packages or any other database loaction you like. The loaction already is a variable in src2pkg -it's just not an 'advertised' option. Look in /usr/libexec/src2pkg/DEFINES around line 108, or so. There is this:
! [[ $ADM_DIR_NAME ]] && ADM_DIR_NAME=/var/log
So, if you put this in your conf file(or in the personal conf file of the user):
! [[ $ADM_DIR_NAME ]] && ADM_DIR_NAME=/usr/local/var/log
or even like this:
! [[ $ADM_DIR_NAME ]] && ADM_DIR_NAME=/$HOME/var/log
that should do what you want(?) as far as the database files. Note that src2pkg doesn't really use this directory location except when the -I(REALLY_INSTALL) option is used. src2pkg has its' own internal mini_installpkg(bottom of 15-make_package). I guess you'd still want to hack install/removepkg and pkgtools, though.

I'll try to accomodate what you want, where possible. I have one other user who is keen on having multiple users create personal packages, so some changes have been made for the upcoming release. You should be aware that you can still control things globally which you don't want your users to change. The global conf file /etc/src2pkg/src2pkg.conf is read *after* any personal conf file ($HOME/.src2pkg.conf). Anything you want to override should be put in the global file without the conditional check. Say you want to force each user to use their own $HOME for all temporary files, even if they try to use /tmp. Say the user tries to use this in their personal conf file:
! [[ $SRC_BUILDS_DIR ]] && SRC_BUILDS_DIR="/tmp"
Using this:
SRC_BUILDS_DIR="$HOME/tmp"
will force it to what you want.

Have a good read through the DEFINES file for other stuff which might be useful. But, everything in there should be usable by putting it into the conf file instead of having to edit the main src2pkg files.
I hope this helps you and do let me know if something is not working. I'll have a check on a couple of things meanwhile.

Thanks Piete and Gilbert for the suggestions and comments.

What I want to do is to keep a clear separation between three areas: the basic core system, /usr/local and the programs installed into the $HOME directories.

I have always compiled to /usr/local but housekeeping was tedious. Nevertheless, I could always be confident that everything below that was Slackware current or earlier. If I made any changes to the base system, then I was conscious I was changing the base system and by proceeding in that manner, any changes to the base system were minumum, certainly not frivolous, and easy to document.

The $HOME directories can contain whatever the user wants, frivolous or not. For example this was necessary in the early days of the firefox browser (phoenix, firebird) and its extensions - some extensions had to be installed into firefox's program directory requiring root privileges. By installing the browser program into the $HOME directory there were no such problems.

I am looking at that now and that seems an excellent solution for the $HOME applications. Users already have $HOME/local/bin in their path so I hope a soft link to the application directory will help it work.

Yes, it is not a good idea to change them. I need to think more about how the conf file can be set up.

Thank you both very much.

Michael.

Keep this in mind:
When src2pkg script is run, the package-specific variables are set first at the top of the script, before sourcing the FUNCTIONS file. Running the src2pkg does the same thing, excpet the package-specific options are passed from the command line.
either way, once the FUNCTIONS file gets sourced, the rest of the options will be set or read in in this order:
1. personal conf file
2. global conf file
3. DEFINES file
this all happens at the top of the FUNCTIONS file and is done at the time of sourcing the file. All the rest of the code(the functions themselves) is only run later whe each instruction gets called.
The conf files are optional, so any essential options are set in the DEFINES file, excpet that a few things can only be set after do some processing. This is why some stuf doesn't get set until pre_process is called. This construction:
! [[ $VAR ]] && VAR=VAL
is used repeatedly to allow for orderly setting of vars. You can always override global settings from the command-line or on a per-package basis with a script. As shown in the eralier post, you still can override users settings by using absolute syntax in the global conf file.

I see the value in letting users install progrs in $HOME, but you'll need to provide a slightly hacked pkgtools to accomodate that. I'm pretty sure src2pkg can be coaxed into cooperating with such a structure, but there may be a couple of glitches still as this is pretty much untested.

Do you mean to allow users to create their own packages, or do you simply want to offer generic packages made by root or admin, which can be installed in $HOME?
Sane handling of /usr/local is a little trickier as stated before as it implies that src2pkg second-guess your intentions or not. Not doing so can lead to poorly-built packages. the problem is to separate handling of /usr/local from other valid(?) subdirs which get created under /usr. The best thing I could come up with for most(nearly all) users benefit, was to have srcpkg try to do the Slackware right Thing. The CORRECT_XXX features are optional, but they are on by default since most users simply want to install src2pkg and start to build 'good' packages without having to set up a bunch of options. A I said, if anything is not working like it should, I'll try to get it fixed for the next release, if possible.

Another thing to keep in mind about /usr/local which Piete mentioned, is that /usr//local/bin preceeds /usr/bin in the normal users PATH, so programs which install there override the normally installed ones. This may be exactly what you want -or maybe not.

Again, I am interested in your ideas and needs as not many people are using src2pkg on multi-user systems. So your input and feedback help with getting things going in a reasonable way. One user has suggested that there be a src2pkg group. I don't really like the idea of having to create a new group and include a normal user in it just to be able to run src2pkg. But, it might be a good idea to limit the use of personal conf files to members of a group. As it is, I'm about to add a bit of code which check the exit status after sourcing any personal conf file, as a way of offering a bit of sanity checking. rthe thing is that the conf files are executed in-line just like a script. So a user could put anything they want there. of course, normal read-write permissions controls are still in effect. This is why building packages as a normal user is safer, since any 'stray' commands which would change real system files will be denied. Some users have suggested the use of fakeroot before, but I decided against that because it opens up a real risk of giving a normal user arbitrary write permissions. src2pkg uses a feature of 'tar' which resets the ownership of files in the archive to root -this allows for making sane packages as a normal user, but where the files all belong to root as they should be. A hacked pkgtool would allow these packages to be installed in users' $HOME without problems -the ownerships would be set to the user in that case on unpacking.

Well, thanks everyone for your comments.

Guess what - those of you who advised against using /usr/local have been proved right!

I spent hours yesterday trying to understand why a program wouldn't install via slackbuild despite having installed the dependency libraries using also slackbuilds.

The reason was because I had compiled another version of the library a long time ago into /usr/local.

Even if it had not been compiled, but installed as a package into /usr/local, it would have taken sometime for me to fathom.

The frustration of having to look in the two places - especially with the difficulty of deinstalling a compiled installation has lead me to the conclusion that, yes, it is better to have all in the same place - and all installed either with slackbuild or src2pkg!

Needless to say, I now take a different attitude towards the idea of installing programs to the $HOME directories - except for self contained application directories - but that too may bring some problems.

So, mea culpe - I should have kept it simple:)

Here's why you've had some problems:

bash-3.1$ cat /etc/ld.so.conf
/usr/local/lib
/usr/X11R6/lib
/usr/i486-slackware-linux/lib
/opt/kde/lib
/usr/lib/qt/lib

bash-3.1$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/usr/lib/java/bin:/usr/lib/java/jre/bin:.

In both the normal users' PATH and in the shared library search path, /usr/local comes before /usr. So any binaries or shared libs under /usr/local -no matter how they got there- get found and used before the 'system' progs and libs under /usr.
And the same is true for roots' PATH also.

Sometimes this may be exactly what you want, but it may be more likely that you want to enable users to have a private copy or build of a certain program that only that users has access to. Like if you want to try out a different version of a program which already installed under /usr. In that case, the AppDir approach works pretty well. It may be difficult(impossible) to package (as root)some programs for use in $HOME dirs. Many programs have their lib, data and sysconf paths hardcoded into the sources(or determined at compile-time). Some will let you use a relative path. My AppBuilder archive has a couple of example patches in the documents which can be used to help you patch some sources configure and/or ltmain scripts so that a program will compile using a relative path.
If this won't work, that means that each user must compile the program for themselves so that the prefix gets set to their $HOME/bin or wherever. You could also, with some effort, create an area where programs could be placed and only be in the path when and for who you want.

I did a considerable amount of work the last couple of days to get src2pkg working better for some of what you wanted. I implemented a COMPAT_STYLE option which controls the corrections and paths of packages. It seems to working okay where you can use a '--prefix=$HOME/local' and all the package files will get placed there.
I also implemented some more routines having to do with controlling and configuring src2pkg for use by multiple users on the same system. I'm still interested to know what you are trying to achieve.

That would be great - please watch this thread - it will be interesting one way or the other.

Basically just to make available to the user, that which is available to root - the same ease of installing and de-installing packages into the home directory as root has installing into the other directories - ease from the point of view of housekeeping, not in any other way. Clearly we are talking about a $HOME/var/log scenario.

I don't have a multi-user system - I maintain 3 independent PC's - I installed the system and I leave the users to do what they want - and they don't want to meddle with "root" or su etc. I try to keep their systems identical - apart from /usr/local - that will now change.

Hence all this is more for my benefit ultimately than theirs - I'm the one who has to clean up any mess. Hence I started the thread in the software forum.

I have realised that I am (was) in a minority of one with regard to the use of the /usr/local directory - for what I now see are good reasons. I come from a background (in my early days) of IBM machines and I simply jumped to the wrong conclusion about /usr/local - compounded by the fact that all the programs I have installed onto the machines I compiled myself. Regretfully I didn't visit this forum often enough - and since I have only just upgraded from slackware 10.1 I wasn't aware of the progress that had been made with src2pkg.

As you realise I am very excited with what scr2pkg and slackbuild can do. And had I stuck to conventional wisdom, I would not have had so much of problem that I had yesterday - compounded by the fact that I had so much compiled into /usr/local, instead of being installed and registered using tgz packets - de-installing was unnecessarily difficult.

The idea of installations to the $HOME directory is, I believe, valid, because of the rapid changes and choices in programmes such as browsers, the independence of software such as thunderbird from other systems such as procmail, sendmail etc. if the users are using pop3 mailboxes such as their ISP or yahoo etc.

However - that is only what I believe.

I don't want to be responsiblre for you putting in a lot of hard work for one exceptional case - even if I'm the one:).

Hence I hope the thread I started will catch peoples attention and we will get a good response - and then the believing can end and the knowing can start.

I now feel, rightly, very guilty with regard to the fuss I made about /usr/local and the work I have already caused you, Gilbert - but I believe the matter regarding installing to the $HOME directory and application directories is something that will have a wider value - but what I believe is one matter - what is reality is another.

In any case - being able to install a tgz file into the $HOME/local will be great - conflicts caused by libraries in the user path are not a problem of the package generator. The application directory generator would be a solution for that (the firefox/opera directories I have installed in the $HOME directories are good examples that function well without such conflicts).

Even though I have these directories I had never thought of or even heard of this concept until you and piete mentioned it - hence I cannot yet make any contribution to help you in any way - but I will now start thinking about that more.