GNU autoconf doesn't create the ./configure script automagically out of thin air. The script is generated from a template, usually configure.ac or configure.in. Are you going to write that template yourself?

Well, there is a helper tool (autoscan), but you'll have to manually complete the generated configure.ac nevertheless.

But this isn't worth the bother. GNU Autotools is a very complex system. Rather than autotoolize the package, much easier is just to use whatever build system it already has in place.

In your case, it's the ./Installer.ksh script.

1 members found this post helpful.

Ah, I see, thanks.

If only it was that simple…

Autoconf will not create a configure script out of the blue. It needs a template (written with M4-based Autoconf macros) to do that. And then the generated configure script needs Automake templates to generate the final Makefiles.

Basically to “autoconfiscate” that project, you would need to fully understand everything that the custom installer script installer.ksh is doing, then re-implement that script in the form of Automake and Autoconf templates. That would be quite a challenging task.


There’s no top-level Makefile because the whole “build system” is in that custom installer.ksh script. As I’ve said somewhere above, NsCDE developers seem to suffer from Not-Invented-Here syndrome, and made their own build system instead of using any of the well-known build systems available out there (that would be reason enough to stay away from that thing, in my not-so-humble opinion).

1 members found this post helpful.

Thanks, in your earlier reply, you said I'd just like to make sure I understand, so by installing the program into a /tmp/<build_env> and patching the installer script to replace any mentions of /opt/NsCDE with /tmp/<build_env (actually, why do you call it "/tmp/build/opt/NsOCDE"?) it installs it into the /tmp/<build_env> instead of /opt/NsCDE and from there I can try building a package out of it?
I would've thought I'd have to patch the installer script so that all mentions of /opt/NsCDE are replaced with a pointer to a variable holding the value of whatever the final package directory would be? Or would that kind of thing not matter anymore once it's in the hands of makepkg? Actually, if I install the application within /tmp/<build env> then would I need to uninstall it again after I've made the package so I can install it from the package? Sorry if this is all a bit frustrating, I do fully intend to read more on this over the coming days on the slackwiki, the slackbook and any other documentation I can find.

Wait, have you looked into that installer script? It has an option -p <path>.

1 members found this post helpful.

OK, let’s try again.

The final place of the software, once it has been installed, should be /opt/NsCDE. For that, you need to actually install under, for example, /tmp/build/opt/NsCDE. Here, /tmp/build is the root of your staging tree (that root could be anywhere else, of course; putting it under /tmp is just somewhat logical, as that staging tree is temporary in nature).

Once the software is staged under /tmp/build, you will then call makepkg in that directory. makepkg will create a package of everything under /tmp/build. The resulting package will contain paths of the form opt/NsCDE, so that when that package is later installed on a Slackware system (by installpkg), the files will end up under /opt/NsCDE.

So you understand that we are dealing with two “destination directories” of a very different nature: there is /opt/NsCDE, which is the intended final location of the software; and there is /tmp/build/opt/NsCDE, which is where the build system should actually copy the files so that you can package them.

Now, proper build systems are aware of the needs of packagers and know the concept of a staging tree. With the autotools for example, you would specify the intended final location of the software with the configure-time option --prefix, and the staging location with the make-time option DESTDIR. That’s why, with a project using such a proper build system, you usually don’t have to worry too much about this whole concept.

The installer.ksh script, unfortunately, is emphatically not a proper build system, and belongs to that category of build systems called “the Packager’s Bane”. It does have an option to specify an installation directory different from the default, but does not separate the “intended final location” (from where the software is actually expected to run) from the “staging tree” (where it should copy the files).

If you instruct the script to install the files under /tmp/build/opt/NsCDE (which you should, in order to get your staging tree), look at what the installer will do:

The script will bake your installation root (/tmp/build/opt/NsCDE) into the startup script and configuration file. That is, the software will be expected to run from the staging tree instead of its intended final location.

So what you will need to do is either a) patch the installer script to remove the offending lines, so that it does not bake the path to the staging tree into the final files, or b) leave the installer script as is but then have your SlackBuild undo the changes made by the installer script.

I hope it clarifies things a bit.

1 members found this post helpful.

Thank you! That explanation really helped clear a lot of things up for me

Wow! I'm really puzzled as to what the devs were thinking when they made NsCDE like this. I would've thought they'd have been aware of the general practices and install etiquette with how they were adept to write the thing in the first place but I guess they were going for a more quick 'n easy fix than a long lasting one.

As to the editing of installer script destination directories; what would you recommend? That I remove the lines here and now and then attempt to package it? Or install it as is, and patching them later when I eventually try making the SlackBuild?

Well, CDE having been mostly Solaris/AIX/HP-UX thing, and the author of NsCDE obviously being fan of CDE, why should they be aware of Linux practices?

I would recommend you to choose another piece of software that is easier to package. Really.

1 members found this post helpful.

The same thing as shruggy.

Frankly, the more I look at that script, the more I think that I would never want to run that thing on my machine.

Should you decide that you absolutely want/need to package it, then I would probably approach it more or less as follows:

a) Never ever run the installer script with root privileges. From what I see, the script does way too many things and try to touch way too many paths on the filesystem (for example it tries to install things in /usr/local/share/icons and /usr/share/sessions, independently of the -p option), I would never be comfortable running it as root. Do everything as a normal user and switch to a super-user account only for the last step of the packaging process (that is, for the actual call to makepkg).

b) Study very carefully the installer script to understand exactly what it does.

c) Run the installer script (again, as a normal user) to install the software somewhere (let’s say /tmp/test_NsCDE).

d) Check that the software is working as intended in /tmp/test_NsCDE (no need to go further if there’s already a problem here).

e) Move the entire /tmp/test_NsCDE elsewhere (e.g., into /tmp/test_NsCDE_moved), and try running the software again. It will probably fail, because as explained above the initial installation path /tmp/test_NsCDE will have been “baked” into some of the software’s files.

f) Find out what you need to modify in order to make the software able to run from its new location. There will be at least the bin/nscde and the config/NsCDE-Main.conf files, from what I have seen in the installer script, but there may be more than that.

g) Curse the NsCDE developers. It won’t actually make the packaging any easier, but after the previous step it should make you feel better. Don’t do that if you’re working in an open-space, though.

h) If you manage to make the software runnable after having been moved, then you can try packaging it. Move it again to /tmp/build/opt/NsCDE, re-edit the files you found at step f to account for the new location (minus the /tmp/build root); then, as root, change the ownership of the entire /tmp/build tree to root:root and call makepkg.

i) Try installing the package you just obtained; the software should now be in /opt/NsCDE. Does it work? If yes, congratulations, you successfully built your first Slackware package; if not, go back to step g.

j) Now that you manually built the package, you can start thinking about automatizing the process in a SlackBuild.

---
Alternatively, a somewhat more constructive approach would be, after step b, to modify the installer script to make it support staged installations, and then propose the patch to the NsCDE developers. This would probably take more time, but would ultimately benefit anyone interested in packaging NsCDE on any distribution (not only Slackware).

1 members found this post helpful.

Haha, thanks! I'll remember all of that in future when I return a linux monk and I can actually do all of that with relative ease. You've been a great help, thank you! Though, with it reaching into so many different file paths as part of the installation, I couldn't tell from looking through the installer script, but if I were to use the installer script as is (without bothering to try and package any part of the damned thing) and later use the built-in uninstall feature listed in the installer.ksh, will that remove all the traces of NsCDE from my system? I'd assume it would but if it doesn't I'll wait until I'm more experienced to try bothering with it at all. Or would you not recommend I even use it as is, given the security concerns of not wanting to run it as root?

Regardless, in the meantime I suppose I'll try to package and write a SlackBuild for perl-File-MimeInfo as my first foray into the whole thing. That should hopefully be a bit easier.

Depends on how thorough and careful the developers were when they wrote the uninstall feature.

Again, I would try install it somewhere as a normal user, and check a) that it works correctly and b) that it can be uninstalled cleanly. If it passes both tests, they you may consider installing it for good, even without trying to packaging it.

1 members found this post helpful.

Thanks again. And I suppose the only way to check if it uninstalls cleanly would be to read and understand the installer.ksh script?

Yeah, scan the script, make a list of all the folders it tries to copy things into, and check after uninstalling that there’s nothing left in those folders that wasn’t there before.

1 members found this post helpful.