[Announce] src2pkg-1.9.7 release
 

Finally, after nearly a whole year, I have released a new version of src2pkg. As you might imagine, 12 months of work means that there are *many* changes. The best way to get an overview of the most important and user-visible changes is to the read the CHANGES file.

If you have the inclination (and *lots* of time), you can read a more detailed account of the changes in the ChangeLog file.

The installable package of the new version is here.

As always, I am interested in any comments, suggestions, bug reports or code submissions. These can be sent to me directly at: amigo@ibiblio.org

This new version includes some huge improvements in functionality which make the creation of excellent packages even easier. A couple of routines have been added which do more thorough checks of the package content and notify you of anything 'unusual'. It also now verifies the use of DESTDIR, fixes errors and notifies you of the problem. DESTDIR is often only partially supported by the Makefiles and while installing most of a package in the specified DESTIR, will also install some files to the real root '/' partition. src2pkg now recognizes this error, adds the 'stray' files to the package and lists them for you. Of course this only happens if you are using src2pkg as user 'root'.

src2pkg also now provides an easy-to-use 'SAFE' mode which functions the same way that used to be the only way you could use src2pkg. That is, SAFE mode can be used when running as 'root' and uses no DESTDIR when creating the package content. This provides the most accurate detection of files, dirs and links created by the 'make install' command, using the built-in functionality of libsentry. But SAFE mode also provides a backup functionality which backs up any files which are about to be overwritten by the 'make install' command and restores these files before package creation is finished. As part of the packaging process, the newly installed files are copied into the package tree and then removed from the real location under '/'. This means that even before the package creation is finished, your system is restored to its' original state.

Of course, src2pkg still allows you to build most packages as a normal user -only packages which require unusual directory ownerships (or which have severly broken Makefile 'install' rules) need to be created as user 'root'.

This new version includes a new version of the 'src2pkg-helpers' programs, so you'll need to run the command 'src2pkg --setup' (as root) after installing or upgrading src2pkg.

Also, this new version uses a new syntax in the /etc/src2pkg/src2pkg.conf file, so you'll need to rename or delete any old src2pkg.conf files which you have been using. The easiest way is to simply rename your old conf file to somthing else like src2pkg.conf.bak.
Then, you should have a look at the new src2pkg.conf file which gets installed and see how the new syntax differs so you can make any custom changes accordingly. Of course, the use of the conf file is optional, so if you have been using src2pkg without any changes to the conf file, you don't have to do anything (but it would still be good to get rid of the old src2pkg.conf file before installing or upgrading to the newer version).

Hopefully this new version will prove to be as problem-free as the last stable release!

Gilbert

Excellent timing, I've recently done a clean reinstall and have been packaging up a few bits and pieces as I go, largely from slackbuilds.org while 1.9.7 gets sorted out ...

Some highlights I found in the changelog, that I'd like to share with the class include:
* "User extensions" - being able to run custom code pre- and post- src2pkg function call to extend it without actually hacking on the raw source. As noted, also a great way to test some potential code for later inclusion.
* Auto-adding scripts to packages
* New how-tos \o/
* Gilbert got his name in the kernel changelog, congratulations! :D

Finally, a query about --prefix detection: does the argument passed interatively to CONFIG_ARGS get written into the the build script when using -A?

I look forward to sorting out the rest of my system knowing src2pkg is in tip-top condition, thanks Gilbert!

- Piete.

Thanks for chipping in with those valuable tips, Piete. I didn't want to make the original post too long, so I tried to keep the news short... but the real story is there are around 770 new lines in the ChangeLog for the new changes... I really didn't mean to wait so long to release, but it turned out to be a very long time.

This is a very good question:
"Finally, a query about --prefix detection: does the argument passed interatively to CONFIG_ARGS get written into the the build script when using -A?" and shows that you have already dug deep into the docs {:-)
The answer is a little complex and still under consideration, so I'd welcome feedback on this subject. What you are referring to, for those who haven't gotten there yet, is a bit of code which handles configure scripts more completely and flexibly. The new code is better at filling in configure options for you automatically, or for letting you fill them in yourself or add to the options that src2pkg comes up with alone. Then your question is that if you are running src2pkg with the -A option which writes a $NAME.src2pkg build script for you, if these options then get written to the script. The short answer is "YES", but this needs some explaining.

The original use of the -A option is to automatically write a $NAME.src2pkg script for the build, after the build, if and only if, the build is successful. However, the -A option actually turns on, or off, several operations. And, you can use the -A option anytime to enable these features, even when you are running an already existing $NAME.src2pkg build script -like running 'src2pkg -X -A'. What this does is executes an already existing $NAME.src2pkg *or* $NAME.src2pkg.auto script. In the best case, you'd always change the name of any script you hand-edit to remove the '.auto' suffix -this means it would never get overwritten. But you may forget sometimes. So, usually when you use the above options, src2pkg would detect the fact that you are running an already-existing script and set an internal variable 'DONT_CLOBBER_SCRIPT' and would skip writing the new script. However, in the case you mention, you may be altering the options already given in the script, or 'guessed' by src2pkg. The way this is supposed to work (still tentatively) is that if you change the configure options, then DONT_CLOBBER_SCRIPT gets unset, so that a new script is written when the build finishes.

You've touched on another aspect of this new routine which I'll try to outline -I know you can read the code, but others may not make any sense of it. In the last version of src2pkg, using the -A option would cause src2pkg to look for possible options to the configure script by looking in any rpm '*.spec' or debian 'rules' file. And the --prefix=?? option was always supplied separately from any other options you might use. Both of these behaviours were less than perfect. Picking up configure options from 'foreign' files meant that sometimes the 'guessed' options would contain garbage -- un-parsed text. And, as for '--prefix=??', even that will cause configuration to fail if the configure script is not an autoconf-type script and doesn't accept the --prefix=?? option. A recent case referred to me by a user here on LQ, had just such a configure script which was looking for usage like this: '-pre-fix /usr' -not '--prefix=/usr'. So, now src2pkg tries to detect if the --prefix option will be valid. If not, it opens an interactive dialog like you described and tries to show you the results of running './configure --help', *if the --help option is valid*.
This new routine also allows you to add certain options for every build -if they are detected as being valid. Some users may wonder why src2pkg doesn't supply at least '--sysconfdir=/etc --localstatedir=/var' as these commonly need setting for many packages to make them conform to the usage in Slackware. The trouble is that you can't assume that these option will be valid, so using them always would cause as many failures as it would fix packages which need the options. src2pkg now lets you secify a list of these sort of options which can be automatically filled in for you -but only if they appear to be valid with configure script in question. This feature can be explicitly enabled by using the -ACN option which stands for AUTO_CONFIG_NATIVE. By default, only sysconfdir and localstatedir are in the list of options which src2pkg looks for, but the user can extend the list if they wish, by uncommenting and editing the line:
#AUTO_CONFIG_OPTIONS="sysconfdir localstatedir"
in the /etc/src2pkg/src2pkg.conf file.

The other matter, about picking up options from a spec or rules file has been solved this way: It also has been made an explicit option '-ACF' which stands for AUTO_CONFIG_FOREIGN. Using this option lets src2pkg search for options from a spec or rules file. No one should think this is necessarily bad -src2pkg filters out or translates most common options which are known to be different from standard slackware usage -like --mandir or --docdir. If you use this option in combination with the -Q (QUERY*) or interactive option, you'll still get a chance to correct, add to or remove options before the build continues.

A couple of users have asked about how to get src2pkg to always show them the configure options by running './configure --help'. This is what the -Q option does. But you can use it in combination with the above -AC* options to have more control and improve the chances of getting a successful build the first time. The output from the './configure --help' command is shown in a separate xterm(unless you are in CLI) so you can easily scroll through and read the help screen and still have access to the main terminal where src2pkg is running. You can paste options from the help screen into the main terminal to save typing everything by hand.

One other short tip (sort of) around the same subject: Any extra arguments you pass to src2pkg should be written into the resulting script which src2pkg writes -whether you are using the -N or -A option. When you start a build and already know you want to include some extra options, running something like this:
src2pkg -N -e='--disable-this --enable-that' this-n-that-0.0.1.tar.bz2
will write the EXTRA_CONFIGS='--disable-this --enable-that' line for you into the new this-n-that.src2pkg script for you. Any of the src2pkg *lowercase* options available at the command line should be written properly into the generated scripts.

The range and separation of things that happen with the -A option are still being worked on and considered. This also involves the interactive mode(-Q) which some users like and utilize, so feedback and suggestions are appreciated.

Thanks Gnashley. Very nice update.

Thanks, gnashley:-) Downloading now. I appreciate your hard work, man!

Another thanks, gnashley. Just upgraded.
Seconded.

Great work, Gilbert!

I look forward to working with it (and editing the wiki...). :D

Regards,

-Drew

Ah so, Drew! I was just thinking of emailing you to notify you of the release. I've tried to distill most of the new info you'll be wanting to change in the CHANGES file. The ChangeLog looks more like a novella, I'm afraid. There is one other matter that needs to be changed -a reference to src2pkg being compatible or working on specific Slackware versions -ahh, here's the text from aposting by SqdnGuns:

"Compatibility with Slackware versions

src2pkg has been tested and works with the stable releases of Slackware 11.0 and 12.0."

The way this should read now is that src2pkg should work with any version of slackware (or nearly any other distro, for that matter). Since src2pkg compiles and packages its' own helper binaries and libraries(src2pkg-helpers) and installs them (using the 'src2pkg --setup' command), it can be used on nearly any system which has the 'installpkg' command and the minimal set of compiling tools (plus sed and coreutils).
I do supply a couple of different pre-made packages of src2pkg-helpers on my site, but this is just a convenience and don't guarantee having the package for all Slackware versions available. It really is simpler for the user to simply install the src2pkg-X.X.X-noarch package and run 'src2pkg --setup'. This guarantees compatibility with their system no matter what they are running -it also indirectly checks their system to see if they have the basic compiling tools installed. If they don't, then the build of src2pkg-helpers will fail.

Please don't hesitate to email me with any questions you have -It could also be helpful to ask Piete about things as he is able to read the code very well and does a better job than I do of condensing answers into a digestible form {:-)

Thanks, as always to both you and Piete for your continuing efforts to make src2pkg more accessible to everyone!

Gilbert,

Your edit is noted. :)

I think it will be next week before I can tackle the wiki update in earnest. But once I get started, it usually doesn't take very long -- a couple of days at most. Naturally, we'll want Piete to take a look and add his edits too.

The other thing, of course, is that I'm looking forward to downloading and working with src2pkg again. :D

Regards,

-Drew

Now featuring a higher 'IQ' ...

Thank you very much Gilbert.
I assume this latest src2pkg also works for SW 12.1?

Yes, since the 'setup' command compiles the src2pkg-helpers right on your system, src2pkg will work on any version -at least as far back as Slackware-9.1 and right up through current. src2pkg is also in use on Vector Linux, Zenwalk, slamd64, blue-white, HostGIS and has even been used on gentoo and puppy.