You can't really do this in the src2pkg.conf file because PKG_DIR and SRC_DIR are both derived after crunching the name of the tarball -this all gets done in pre_process only when a build has actually started.

You could do some re-writing of the code there to make something like this happen, but I really think you are going about it all wrong. It doesn't make sense to try to get a program which is designed to make packages not make packages. Most of the code in src2pkg is meant to keep your sources and package separate and most definitely be able to separate these from your already-installed system.

I've suggested to you before another system which comes much closer to doing what you want -the AppDir system which is used by the ROX-Filer and programs. Long ago I adapted the existing structure so that it uses bash only instead of depending on python. And you don't have to use the ROX-Filer in order to use the AppDir build system.

What I did was create a generic AppDir which you can use to wrap mopst ordinary sources with. It consists of a directory which you can rename to the name you want for your app. Then, you place it where you want it to reside on your system. Inside the directory thewre is a script called AppRun. You edit that and put(at least) the name of the executable the sources will produce. Then you place the uncompressed sources inside the directory. The script looks for them in a generic subdir called 'src', so you either rename the main source dir to 'src' or create a link. then you just run the AppRun script. It compiles the sources with a prefix which matches the location of the AppDir and installs the the program and other files right there inside the AppDir and cleans up the sources(make clean). If you do happen to be using ROX-Filer, you can see the full magic -ROX-Filer ecognizes these AppDirs as being an executable, so that when you click on the directory it runs the AppRun script. This means that you just click on the directory and it gets compiled and run. This system also allows you to have binaries for more than one arch in the same directory.
This system really comes alot closer to doing what you want and it could be automated somewhat more since you want to do everything this way. I never worked on that more because it is a mostly unknown system. The guys at ROX have worked out other systems which also are very slick -these all involve the way software is delivered to your system, but all of them have this in common -that the software is compiled on your system to match the arch you are running.
The AppRun script for each AppDir can be linked to from wherever you like so you can use whatever paths you like.

I suggest you try an example program so you see what I mean:
http://distro.ibiblio.org/pub/linux/...Term-0.4.2.tbz

Just download that and decompress it wherever you like. It will create a directory called ATerm. Then just cd into the dir and execute it like this:'./AppRun'
That should compile, install and then start the program right there in that directory. Of course, once compiled, the next time you run the script it will simply run the program. The binary will be installed in a dir that matches the arch you are running. You can create a link in the path of your choice -normally this would be in /usr/bin. I keep my AppDirs in /usr/apps, so my system has a link like created like this:
ln -sf /usr/apps/ATerm/AppRun /usr/bin/aterm

The nice thing about the AppDirs is that they are self-contained and very felxible(even more so if you are using ROX itself). I have quite a few of these that I use every day, which are only wrappers for programs installed elswhere or for more complex scripts which take advantage of drag-n-drop-ability. Since the AppRun script itself picks up whether something has been dropped on the AppDir(or the link to the AppRun), then you can create some ineteresting applications that way. Here's another example that I use sometimes hundreds of times a day:

http://distro.ibiblio.org/pub/linux/...ZipZap-1.0.tbz

Zip-Zap is a wrapper for creating or extracting archives. The drag-n-drop feature makes it very easy to work with archives. If you drag and drop and archive onto the AppDir(or link) it will deacompress it in the same directory where the compressed version is. If you drop a file or directory onto it, it will create an archive from it. It uses Xdialog and other small dialog-type utilities to create the GUI components which offer the options. It won't work for you 'out of the box' unless you already have Xdialog:
http://distro.ibiblio.org/pub/linux/...ialog-2.2.1.1/

and greq installed:

http://distro.ibiblio.org/pub/linux/...og/greq-0.9.4/

Even if you don't install them, having a look at the AppRun script for Zip-Zap should give you an idea of how flexible the system is.

To create your own AppDirs easily(especially for self-compiling programs), I created a generic AppDir here:
http://distro.ibiblio.org/pub/linux/...uilder-0.4.tbz
Just follow the directions at the beginning of this post -change the name of the directory, fill in the name of the executable and change the icon if you want -it should be an xpm called AppIcon.xpm or a .png named .DirIcon -usually 32x32 or 48x48.

I don't actually want to eliminate the building of packages. I just wanted to change where they are built. But since I already know to some degree how to change what I want, I will do that instead. I will basically just change the system, so that the $PKG_SRC is a subdirectory of $PKG_DIR. Since both of these are deleted each time a rebuild is issued, it makes sense to just keep them as temporary directories, which is what they are. So, I will simply place them in my /programs/category/$NAME/$VERSION/$ARCH/work.
In this case, I am essentially replacing $CWD/tmp with $CWD/work. So each package will have it's own temporary compilation directory. But I need to take this into consideration with ccache, since I am now using that as well. I guess it might be possible to allow ccache to see each package's /work directory as a ccache directory. I'll have to try that and see. No! Wait a minute. Since src2pkg deletes the $SRC_PKG directory, it has no means of supporting ccache, which is too bad. So there's no point in even looking into that, unless you later provide support for ccache.

As a side note, I am now attempting to write a src2pkg script for building the Condor HTC system. Which brings up yet another interesting point. I tried compiling one of the external packages for Condor, and it opened a separate Xterm in the process. Since there is no current way to deal with this in src2pkg, src2pkg failed. I will send you a copy of the tarball, since it is small, and I know you don't want to download the entire Condor source (which is over 200mbs), just to see one example of a new quirk in packaging techniques.

Shingoshi

Hi gnashley,
Just stopping by to say hi. Haven't been here in a while and wanted to see what's happening. I'm using Gentoo now in full force, but still have need for src2pkg, as there are plenty of sources out there which need it.

Drop me a line when you have the time and tell me how you're advancing with your work.

Shingoshi

Will do, I'll send you another beta copy to be sure it's compiling correctly on 64 bit. I also have some ideas for you on how to do what you ask about -that is, getting stuff to install in the same place as the sources. I've waited a long time to release as I have made nu erous small changes that needed testing and I have been busy with some highly-patched sources and weird stuff. You mentioned having built some gpe stuff -the other day I was working on getting the Matchbox window Manager & Co. working -pretty neat light-weight stuff.
I've found a few new GTK-1.2 proggies to add to my collection, including a very nice PDF/PS viewer, some display adjustment tools and also very nice patched versions of dillo and sylpheed claws with lots of extra goodies. I have sylpheed working with a dillo plugin, so now I can even browse the web from inside the mail client!
Also, I have a kernel patch which is supposed to be incorporated in the next 2.4 series -it's a backport of the 'rootdelay' feature from the 2.6 kernel -very useful for booting from USB devices without the need for an initrd.
I'm really considering starting a new distro again as I have most of the work done -a distro built especially for running from USB devices, CF cardbus devices, or for really light, small or slow hardware -think eeePC or any of the other recently-released sub-sub-minis.
I discovered a couple of old projects which provide some really nice features -like a compressed ext2 filesystem which does all compression and decompression on-the-fly and transparently without any special handling. This has the advantage of providing 45-55% space reduction but without sacrificing file attributes or being a read-only image(like zisofs, squashfs or cramfs).
The idea for building a distro especially for USB devices is what gace birth to src2pkg originally -since I needed a way to build lots of packages optimized for size. The last few years I have tracked down apps for nearly everything you'd want for a basic system, all using the same small, fast GTK1 toolkit.
Most people take me for very backward-looking for wanting to use GTK1, and in fact I don't need any more for my desktop (PIII) machine. But the same apps do wonderfully when run from USB, where application size and startup times are critical. Because transfers over USB are really slow, it takes a very long time for the desktop to 'come up' and be ready. What I built is much like a LiveCD, except it runs 'Live' from USB and allows for 'normal' handling of programs. I mean you don't have to learn special tricks to add or remove software or save your config files. The whole thing is read-writable, but in a way which doesn't trash FLASH devices right away. One of my major 'beefs' with LiveCD distros is that the user has to learn so many 'non-generic' things or has to use the system in very non-standard ways. I mean about adding 'program modules', remastering or having to run as 'root' or having other limits to real multi-user functionality. I wanted to build something which would guide these users into the mainstream UNIX way of doing things -no matter how flawed that may be.
Speaking of that, I wanted to comment on your recent idea of re-organizing the file system layout. To do so would be to go against some very good reasoning, against nearly every other developer(you can't do it all!). All the projects which intended to do this have died(except GOBO) for one good reason: the filesystem is just an abstraction of the hardware anyway -what you want to do to simplify things can be much better done by simply adding another layer or type of abstraction. Mac OSX does this by hiding the real filesystem structure behind the GUI. The ROX-Filer also provides a pretty easy way to do some of what you want -withiout having to re-write the book. Basically you just need a filer which only shows what's interesting or useful to the normal user and hides the rest. What you choose to show can be arranged any way you want without having to change the real underlying file system layout.

When I have gotten a new distro together you'll see what I mean...

Since I've started working with Gentoo, I've been working with a developer who created the portato package manager for portage. I've made some useful suggestions. But realized just tonight that I'd been a complete idiot about something I was pushing him for. And frankly, I don't know how I missed it, or why he was so patient. Anyway, Necoro has been a blast to work with. I would really like to twist both of your arms into working together. But both of you claim not to be interested in the kind of thing the other does. And that's really too bad. He makes a fantastic gui, and you make a fantastic source-package builder. If they were combined, no one would ever need to look anywhere else for a system to be as complete as the merger of your two projects.

I've really made good progress with my project also. I have abandoned some ideas, and still looking for ways to implement others. I've contacted the Gobolinux group. But I'm really not ready to deal with that yet. For one thing, I can't take on too much heavy building, until I replace my motherboard. I'm seriously considering the purchase of a quad-socket system board. But to do so, means restricting some things. The board in question is the Tyan s4980. It has only 6 SATA sockets on it. My chassis will hold 8 drives, and presently has 2 IDE drives in it. And, it only has one pci-e slot. So I have to decide which is more important to me. Having a video card, or a drive controller. I could use this board, if I eliminate my CD/VD Writers. That would be somewhat of a pain. But I could put them in one of my other chassis. And I have to make up my mind soon, as I'm dragging my @ss not doing much of anything. All of this could be alleviated by using the machine strictly as a background compilation server, and logging into it remotely, or using one of the remote controller programs available.

Why am I telling you all of this? Because it's frustrating not having everything you want, to do anything you want, when you want to do it. And I'm sure you know how that feels.

Your interest in minimal systems may come in handy to me. I have thought about having a complete OS installed in my /boot partition. So in effect, /boot would be it's own separate "/". The reasoning behind this is to have an immediately available emergency recovery system for the user, without having to boot from an installation CD/VD. I've already mounted my /lib/modules as a separate partition, reachable by both Gentoo and Slackware. It's working just fine. Since I boot both systems with the same kernel, I thought why should I maintain separate kernel trees for both of them, and simply instead just combine them.

I've also made my portage tree available to both systems. Mostly though, that was due to space constraints on my Gentoo disk, and not wanting to package the distfiles with my stage4/5 distribution. Basically, I'm building a complete system, fully pre-configured for immediate use from installation. It currently has ccache and distcc up and running. So no one has to do that for themselves. I've also set up the local rsync repository for departmental installations. I'm using as many of the fastest download/installation tools provided by Gentoo. I'm really finding Gentoo to be a dream for this. The only thing I need/want now, is for you and Necoro to make portato not only be able to install ebuilds, but to be able to create them as well, using a modification of your src2pkg. He's been really patient with me. But then, I've tried to support him as much as I can. I probably use his package more than the TEN next heaviest users combined. Since I've switched to Gentoo, I'm now using portato, where I would have used src2pkg in Slackware/Slamd64. But I still need src2pkg. For one thing, Gentoo has no automatic script writer for ebuilds, and I think you mentioned you were considering doing that. I really wish you would, because the one thing that differentiates Gentoo users from Slackware and others, is that we Gentoo buffs spend all of our time building the packages we want to use. So what better target audience could you ask for with src2pkg, creating ebuild scripts from sources. And have you really looked at the bug tracking system for Gentoo? These guys are serious!

Take a look at http://forums.gentoo.org, and look for me or Necoro. Or better yet, just find portato. He's recently posted some pictures of what it looks like. I've pestered him so much on changing things with the appearance, and some of it he's done. It would be nice to convince him to make src2pkg available as a plugin for portato. I mean the whole purpose of portato is to provide a package selection and build environment. But currently, portato only builds what's specified by the ebuilds. I'd like to add to that, src2pkgs ability to make them from raw sources. And if the two of you worked together, he would have the intimate knowledge of Gentoo to help you complete that task. And it would put his package sky high above everything else. And you'd come away from this with a gui that's quite strong and getting better every day.

Anyway, I'll leave it here for now. I hope you and the family are well.

Xavian-Anderson Macpherson
Shingoshi

"I have thought about having a complete OS installed in my /boot partition." -Long ago I had the idea to create a system which would provide a sort of repair-mode or safe mode for doing repair work or upgrades. My idea was to just use a fairly large initrd which would provide boot-time options. It could be made to mount its' own '/' on the real '/' partition using a crude sort of double-mounting. What I mean is that if you mount the initrds' file system and then mount the real partition to the same spot, you'd have a backup system *underneath* the mounted '/' partition. It would be available during bootup, after unmounting the root partition at shut down and anytime you had a system failure. This is because you can mount more than one filesystem to the same point -even without unionfs. When you unmount the second filesystem the first one is still there. A similar trick can be demonstrated like this: create a dummy mount point, then create some files in the directory. then mount some device to that directory -the new mounted filesystem will be available. Now unmount the device and you'll see that the original files are still there and now available. Even trickier - create a filesystem *image* file there, associate it with a loop device using losetup and then mount a device on the mount point. The filesystem image is still accessible through the loop device even while the regular device is available through the mount directory.

As far as integrating a GUI into src2pkg, I'm still quite skeptical about it. Rememeber that the basic idea at the start was to eliminate interactive usage -mainly as a way to insure the repeatability of the build, but also as a way of making src2pkg easier to use. I mean, if it can do what it's supposed to, why should it stop and ask you for confirmation? The newer interactive functionality is a compromise for those who like to help along the way or that want to always get a successful build the first time. It's far from perfect and I do plan to work on it some more -mainly to help in deciding about the best method to use for creating the package content(the REAL, JAIL or DESTDIR methods). I mean that src2pkg could check and see if DESTDIR is supported, and if not, ask you if want to try the REAL method or the JAIL method, for example.

About using gentoo e-builds, I found that the syntax of the e-build files was going to require a *lot* of code in order to interpret them. I found it much easier to integrate compatibility with CRUX ports or other similar systems (ARCH PKGBUILD, for example). Even rpm spec files are easier to extrapolate info from then e-builds. I do still have ideas to maybe integrate some of these into src2pkg, although it seems to be a better idea to implement it as a separate program which calls on src2pkg to do some of the work. I have, for a long time, thought of making it possible to create other kinds of packages using src2pkg. This in itself would require some new code, but not a whole lot of complicated stuff. The work done in analyzing the sources, configuring and compiling is much more complicated than what happens after the package content is created. It'S quite easy to move stuff around and add or delete conetent once the basic content is created. gentoo uses a really large self-contained system for building packages. It would be quite difficult to emulate the most complex part of its' functionality without adding quite a lot of code. Feel free to prove me wrong by writing a shell script which will parse an e-build and spit out intelligible strings to pass to configure...
Most of the work for creating different kinds of packages is best done by separate modules or some other program entirely -like 'alien'. Still, most distros now conform to pretty standardized directory structure -it's mostly in the accessory files like documents and manpages where they differ, and significantly, the configuration files and methods. These last usually have to be handled correctly at compile time, as well as when arranging the package content, since the 'sysconfdir' gets compiled into the program(hard-coded) The same is true for shared-data files. The actual packaging is then easily handled by using the native package-building software -rpm, deb_helper or whatever. And, critically, programs which need conf files in order to work correctly (for example system daemons or window managers) can never be built without intervention anyway -every distro ahs their own way of handling these things and it would take a really complex program to sort it all out with any measure of success.
In a way, it's unfortunate that src2pkg was written firstly to create Slackware packages, as it limits the relevance of my work and the program -since the user base is limited and the typical Slackware user is so self-sufficient. Still the thing that src2pkg is best at and that no other program does, is figure things out in a mostly-generic way and act on that. My recent efforts to get it to use already-supplied human input, that is, getting it to use info from spec files or debian rules files -this has been my first steps toward better usability with other distros, as well as 'cashing in' on that human intevention for the benefit of the Slackware user. Extending the ability to glean info from other build systems is really complicated and means emulating much of the behaviour of the other build systems, which makes for lots of spaghetti code. I always try to keep my scope under control -note that the src2pkg 'program' is an add-on to the underlying script-driven functions. It'S simply a small wrapper which uses the src2pkg functions creatively. In line with this philosophy, most of the ideas that you have had are best handled in this same way. The package building functions themselves should each have a pretty limited scope. This is what makes it them robust, and simple to use or extend.
Surely I've rambled enough for now...

My idea of the root-in-a-boot, was to always boot the system using it, check filesystem consistency/integrity among other things, and then proceed on to boot the main system. I haven't played around with it yet, but I don't think it will be all that big of a deal to do. The idea is to have network access with the "command console", so that if you need to download files from the internet to repair something, you have a full system to work with. Though it would be smaller than the standard system. I thought about using a heavily loaded busybox and uclilbc. But I have sometime yet to work on that.

Shingoshi

I realize now that you've explained the difficulty in writing scripts for ebuilds, that you're quite disinclined to do it. But the basis for merging portato and src2pkg rests here.

src2pkg can be set up to use specific directories for sources, building and packaging them. portato provides the ability to navigate through those directories quickly, and select which sources the user wants to build. Now that you've seen the picture of what portato looks like, you'll remember the text line for conducting searches. That box could be used to search for any source or package in the src2pkg directories. Once you've found what you're looking for, you could then specify options for the build of any package in that line. That (command) line could also be used for downloading sources from the internet, creating the directories for them beforehand or any other set of functions a user would want.

That was the basis of my suggestion. But I guess now at this point, there is none.


Shingoshi

We seem to have the same idea about the mini-boot system. I also thought about having it always boot using the small system. It would be much liie a standard windows boot -defaulting to a regular boot unless you pressed a ceratain key or keys during a small wait period. Doing so would cause the mini-system to enter into repair-mode or other interactive mode. After working there a while, you still have the option to continue booting the normal way.
You are right that it could be a rather normal looking system in /root or wherever, but the best way would be to use an initrd for it. There are two good reasons for this: An initrd is better suited for handling the chroot process to do a normal boot, and using an initrd would let you be able to boot such a system from another device -a CD or USB device, for example. In fact, even if you placed the initrd into the /boot directory (I mean if that's a boot partition, preferably the first partition on the disk), you'd still be able to boot with the initrd even when there was file system corruption. This is because the bootloader (grub at least) is able to access the partition even if the files system is corrupt.
Much of my work toward creating a small GUI system has been done with this in mind -the end result to be a small, but capable system with a very basic GUI, that would include network, anitvirus, repair and installer capabilities.

About portato and portage, you are right that I'm pretty disinclined to go that way, because of the complexity of implementation. The other build systems I mentioned are much easier to deal with. There are several ports-like systems which all do about the same thing -they basically have you write only one function for a build, which covers the configure, make and make install steps. All other actions are done automatically by the build system using default behaviour. At first src2pkg was much the same. I just decied that it would be best to have a larger set of 'public' functions in the 'API' to allow for maximum flexibility n creating/modifying build scripts. Incorporating compatibility with these systems is really easy since they just have a single function which replaces the three most cerntral functions of src2pkg. In fact I have already created a modified src2pkg wrapper which will work with port Pkgfile scripts. But I'm waiting to implement this later as I'm trying to get src2pkg worked into a really, really stable and dependable release for 2.0. I didn't really intend to have the release numbers be taken as a measure of stability, but many users thought that version 1.0 was a 'stable' version and that those that followed were 'development' versions until 2.0 was reached. This has not been the case, but after considering the matter, I've decided to go along with the idea, sort of. Staring with 2.0, even-numbered releases should be stable and will get a micro number only for bug-fixes. Odd numbered releases will be use for adding new features and wil be considered development versions. This should make it a litle easier for usersa to know what they are getting, or to be able to fall back to an earlier, stable version if need be.

src2pkg might one day get a GUI front-end, but this is not really on my TODO list. I don't really have ths skills to write real GUI programs, althoug using gtkdialog would probably be fine for the job. Trying to maintain both a frontend and backend alone would be a lot of work. I am much more concenred with keeping the back-end as stable as possible and addding functionality until there seems to be nothing lacking. This is extremely important -src2pkg has 'rm -rf' in quite a few spots- just one little bug in one of these places could cause so much misery for me or any other user, and so much bad press that I might never get over it.

I don't really even need src2pkg to create ebuilds. It was only an idea. What I really need, is the directory management system for distributing the packages that have been created. If later on, someone comes up with a way to write an ebuild maker from src2pkg scripts, spec-files (which I think you said src2pkg can do), or any other kind of packaging script, great. I'm even contemplating doing the unthinkable ;-D and creating rpms, since that is the most popular method of packaging in the business community. So I have more time to think about all of this. None of it is yet written in stone, so to speak.

I just wanna build packages!
Shingoshi

As I'm sitting here watching a queue of 115 packages being built and managed with portato in Gentoo, it occurred to me, I'd like to include as part of my packages documentation, the build log of the compilation. How would I go about doing that with src2pkg? Am I correct that src2pkg does in fact create a log of every build? If so, is it always in the same relative location? With emerge, it always in /var/tmp/portage/$category/$package/tmp/build.log, which is nice, since I was able to create a script to copy those logs to my /pub directory, where I can easily store and post them to bugzilla.

But I want to have every package which is successfully compiled, include in it's documentation, the build log of the compilation. Please inform me of my options here with src2pkg.

Shingoshi

Gnashley,
Here are links to the projects Necoro is working on. The one we've already discussed, is portato, the package manager. The other which I hadn't looked at before now, is Catapult. It seems to be divided into two components.

Portato: http://portato.necoro.net/ http://forums.gentoo.org/viewtopic-t...ighlight-.html
Catapult: http://forums.gentoo.org/viewtopic-t-674939.html
PortatoFS/CatapultFS: http://forums.gentoo.org/viewtopic-t-676619.html

Take a look at his CatapultFS concept, and tell me how it might apply to anything that you (or I) have conceived of doing.

Shingoshi

Here's a post in which I mention an idea I had not yet shared with you. Rather than repeat myself, I thought it best just to put the link here instead. You'll find the reference to you at the bottom of that post. It's about reverse processing for src2pkg.

http://forums.gentoo.org/viewtopic-p...5.html#5048375

Shingoshi

I thought I should correct something that gnashley wrote, concerning the structure of Gobolinux, even if it may be old.
But I add a bit of new stuff too, soo .... as the topic refers to packaging things.

And I think the best way to do this are flexible AppDirs.

'The /opt directory on Linux systems was especially created for just this purpose or for any app which doesn't use the standard directory layout.'

Gobolinux uses a "standard directory layout", i.e. they are completely FHS compatible. You do "cd /usr" and et voila. You want to compile things into /usr like the FHS mandates and you can do so if you want as well (though this is messy).
But they are much more AppDir-like than anyone else.

/opt was never meant as a replacement for AppDirs/standalone dirs.

Take slackware for example. Sometimes you can find a /opt/gnome but this ruins the whole purpose of an AppDir. You also lose version information.
Contrast this with Gobolinux, i.e. /Programs/LibGnome/2.22.1 and you immediately know the version, and can upgrade/downgrade at will.
Sometimes you even find an /opt/kde3 ... maybe we can say that this is similar to an AppDir but one problem are hardcoded paths as well.
And I am sure that somewhere you have to add /opt/kde3 to the PATH, which is also a situation which won't emerge on Gobolinux.
(Or any distribution that would be built with AppDir like approach)

This simply can not be compared to /opt. Besides, most distribution have an empty dir called /opt. I fail to understand why anyone needs to ship with empty directories, but to be honest I also see no real value in the FHS either.

'I'd strongly suggest that you this structure instead of under /usr, simply because it will help you to keep things more organized by separating the stuff you configure this way from the normal dirs under /usr.'

I think you need to understand that these suggestions are only strategies to cope with the FHS mess.
What is simpler than an appdir please? /usr is a mess too. Hell, I even have had distribution that have a /usr/games directory!
This is a totally wrong IDEA. If anything, then you should put tags onto programs (game, library etc..) and have it in a database-aware filesystem or similar, with different "views" to look at them. But making such a distinction in the FIRST place is silly. /usr/games what then... /usr/video /usr/audio? this is all wrong.... or /usr/local/games, this is the same mess but on another directory.

'One of the 'rules' about /usr is that you are not really supposed to create new directories there -obviously exceptions to this for stuff like mozilla and, historically, X.'

This is one problem. Distributions want to tell users to not mess things up. But they also do not provide AppDirs.

Is it only me that sees this as a problem? If a distribution wants to tag for an upgrade, then they can create files within that directory.

But the moment you install into the FHS-way you lose all that information and are basically FORCED to use the package manager to SURVIVE this mess.


'The problem with this approach and that of gobo is that a lot of extra steps have to made for each and every program and library.'
Not sure to which problem you refer exactly, but I assure you there is no speed penalty I see. I think people create this as artifical
bias against AppDirs in general on Linux - and yes, I mean AppDirs on Linux. No distribution even tries to do this.

I think the guys that did come closest are the Klik guys, but I am afraid Klik will never be more than just a "click to make it run".
And I dont need that (i install things on my hdd and leave it there).

'You may be interested in looking at the AppDir system for creating programs that live entirely in their own dir. I have created a generic AppDir package which makes it pretty easy to create your own AppDirs, called AppBuilder.'

Are you still using it? Because it could be a nice way if many people push into this direction.

Yet I hardly ever read about it. Either the idea is BAD, or it is not popular, or it has some problems.

In theory though, it should be great to have everything neatly self-contained.

Yes, I still use AppDirs every day -just been thinking the last couple of days about creating some more. I really like the concept of AppDirs -but they are not very popular. The problematic point is that you still have to link the program into the normal PATH, or add the unique path to each program to the PATH. Processing a PATH variable with thousands of paths takes up a lot of time. If you installed even libraries into appdirs, then every program would have to include some statically-linked code which would enable it to search for the libraries it needs.

AppDirs make more sense with a system like ROX-Filer, since it recognizes AppDirs as such and simply clicking on the App Directory runs the program. I like and use many ROX AppDirs, especially because of the extended capabilites which can be easily written into the AppRun script. However, each program must get some special treatment in order to install this way. I personally maintain over 1000 packages so I have some idea as to the scope of the problem... Actually, many of the ROX AppDirs I create are simply wrappers for programs which are installed normally. this allows me to take advantage of the flexibility of the AppRun script while still taking advantage of the 'standardized' installation -a self-contained AppDir still needs a link to the PATH in order to use it without ROX.

There are very good reasons for the FSH being the way it is. Until someone comes up with something better which provides the same flexibility and control, we are stuck with it.

The thing is, there really is no need to re-design the underlying file system structure. As GOBO demonstrates, you can easily work around it with an overlying abstraction layer. A file system is already an abstraction anyway, so it's no big deal to add another layer and make it look anyway you want. It wouldn't be so hard to create a file manager which would only 'see' your abstracted layer -this is what MAC OSX does.

Hi Guys!!

Sorry I've been away for so long. Gnashley, I've finally built another 32bit Slackware box (after not having run standard Slackware in almost 2 years.) I decided that it would be best if I kept a separate box for all of my personal activities, like browsing, messaging, posting and email.

So now to the reason that I've returned. I am getting ready to create a modification for src2pkg which will automatically run "src2pkg -N" before every compile. I had already done this before on my 64bit box. But now I'm going to extend the functionality of it to include running "./configure --help" and extracting from the results all of the lines which have "--enable-??", and copying them into the $NAME.src2pkg executable. By doing this, I can then simply edit that file as needed (since my existing script already opens an editor to edit this now: This is an example of how a GUI would be preferable for me, and this will likely become the basis for my doing so). And I just thought of something else. If I include the ability to test for missing executables or libraries required as dependencies, I can create a script to download them from the most common Linux repositories, and build them automatically. In return, each of these would also perform the function for themselves. This is how cpan currently works when set to "follow" to build any required modules for the one initially intended. This is also something which can be copied from Lasse Colin's tukbuild script, as he has provided the ability to search these common repositories and download the needed sources. I'll simply give him credit for this as I always have done with his work.

/EDIT: I'm adding this request as a preface to what I'm intending to do. I checked with "src2pkg --help", and there seems to be no way of getting the current version of src2pkg. I really need you to add this feature for my script to cleanly for every new version.

I will come back and finish this later. But for now, I'd really like to do the above request.

Thank you,
Shingoshi

/EDIT: I've figured out how to get the version of src2pkg. This is the line of code I'm using: "man src2pkg | grep "version-" | head -1 | cut -d "-" -f 3-"

/EDIT: I just realized something. I probably only need to do "./configure --enable-*" to build every available option in any source. That means I only need to add EXTRA_CONFIG='--enable-*' to get every option there is turned on. This doesn't work!! It was only an option for one of the packages I had built.

Shingoshi