Slashdot Mirror
Building A Better Package Manager
SilentBob4 writes "Adam Doxtater of Mad Penguin has published a preliminary layout for his proposed cross-distribution package manager capable of adding/removing software from any locale. He is suggesting the interface will basically allow for installation of several major package formats including RPM, DEB, TGZ, as well as source code with the ability to pass build time options. All of this will come at the price of standards of course, including naming, documentation, and package structuring. If this idea were to catch on, it would signify a major leap in desktop Linux usability. This might be a project that UserLinux might benefit from. Read the full column here (complete with GUI mockups)."
So this is a similar effort to Autopackage except that it plans on using the native package formats? Intriguing...
True story.
I hope they will include Ebuilds as they are a great way to install software, and are becoming more and more popular as Gentoo does.
:) )
(No, this isn't a troll, I'd really like to see that.
libertarianswag.com
When I was your age, we called 'em by their proper name--athletic supporters!
"Package manager", indeed...
Obliteracy: Words with explosions
It's called pkgsrc.
This topic comes up how often? Like twice a year?
And yet nothing ever changes.
This space intentionally left blank.
People get so hung up on the package format. It really isn't about the package format, it's about the people and organization behind the packages and whether they produce a consistent distribution. A "better" package format or a better installer isn't going to help you when a piece of software expects libraries to be there that just aren't available, or when an install script assumes functionality you don't have.
For a simple Windows user, what are these "packages" and why do they need to be managed?
What is so special about this? It seems just eliminating the whole concept of packages would make life so much easier. Installation programs (like MSI files) are simpler, aren't they?
This is not a troll. Please answer my question, don't mod me down.
Lets do this from the beginning rather than slapping it on later.
http://www.openpkg.org/
APT already handles debs and rpms. tgzs should not be a far stretch. The problem is establishing standards and getting everyone to follow them. For example, all debs in the Debian archive follow the Debian packaging standard, else they would not be accepted into the archive.
Naturally, third parties are free to create their own non-conformant debs. This is just the same as someone creating an rpm for RH9, but it not conforming to the conventions used by Red Hat.
I assert that the tools already exist. I.e., we don't need a new one. The emphasis needs to be on getting people to follow the standards, and possibly creaitng a cross-dsitro standard fo everyone to follow.
All smoke and no fire... Don't talk about it just build it. Personally I think someone should sit down and hack together a install package builder program based on something like gdialog and python that outputs a executable compressed image into a single bin file.
A good installer is not hard to accomplish if the desire for it really exists. It is however one of the most overlooked things as open source programs are involved.
Don't make me go hunting down 20 dependency packages but offer to install them for me. A simple script based on wget can do that...
Got Code?
Yeah !
Unify those packages.
I am so often confused the RedHat comes in a red box and SuSE in a green one. - Which of those should I buy ?
And Fedora comes with a box you have to fold yourself...
Oh you mean these packages....
(Fedora Linux is included in the RedHat magazine - which has a foldable page for creating a suitable box)
Spelling mistakes: My is english spoken not tongue of mother.
Why not leverage from the BSD ports system? It already builds directly from source, checksumming the downloads to ensure security, and applies BSD-specific patches. Shouldn't be too difficult to grow this so that source patches and binary packages are platform-neutral.
ps: BSD trolls are dying!
What about 0-Install? It is simple, elegant, doesn't require root to do an installation, seamlessly downloads libraries and other dependancies as they are needed, and integrates nicely into the filesystem. I really think 0Install could be the future of installers, if only they can get someone to build a distro around it.
Essentially there would be some glue between the package management system, the "configurator", and the actual config file.
Sunny Dubey
Sounds like everyone is looking for something like the FreeBSD ports collection.
Don't they know that it's MozillaFirefox and not MozillaFirebird. This installer obviously isn't going to be able to keep up to date.
A musician without the RIAA, is like a fish without a bicycle.
Maybe Apple can do this because they have a standardized directory structure, but what can be easier than dragging an app package to the Applications folder? Poof, it's installed. Don't like it? Delete it. If it's more complex, there's an installer program. Playing with dependencies and makefiles is the reason I gave up on Linux.
"I am not a number! I am a free man!"-- The Prisoner
alien
The theory is fine. The problem is that package managers are, in many ways, incompatible. Debian packages, for instance, track dependencies based on the names of other Debian packages (libfoobaz-dev requires libfoobaz). I've seen package management systems that have dependencies based on files (libfoobaz-dev requires /usr/lib/libfoobaz.so). The former system won't recognize dependencies from packages installed in the latter format. Worse, the packages don't overlap. One distribution will have libgnome, whereas another will have 50 different packages, one for each of the Gnome libraries. The problem of dependencies there breaks almost completely.
.rpm packages on a .deb system, or vica-versa, without breaking something. It is possible to install packages of one sort on the other system, but eventually, things will break. Each package management system relies on some set of information about packages to work, and each system has a different set of information it provides and needs.
.deb, .rpm, .tgz, etc. packages, and give easy-to-read information about what systems it'll work on. I've heard of tools similar to this, but I haven't seen them used. Adding something like this to the standard autoconf/automake/... process would certainly be nice.
There's also a matter of versions and security updates. On Debian, I run 'apt-get update; apt-get upgrade' and have a new version. Since the packages are all maintained by the Debian project (and a few smaller projects that target Debian), this works. Versions aren't linear -- Debian back-ports security fixes. The package manager has no way of knowing whether kernel-2.4.24 is newer than kernel-2.4.19-with-patches.
Basically, there is no clean way to install
There is room for improvement in package management -- a really good GUI for finding and installing packages would be nice. I wouldn't mind having more information about the packages I'm about to install -- links to project web pages, ability to browse installed files (the packages.debian.org/freshmeat.net/etc. databases either installed locally or quickly accessable from the system), the ability to view screenshots of GUI programs, etc. There's a lot of metainformation that could be added, and better search functionality that could be implemented.
At the same time, on the package build side, it'd be pretty simple to have a system where you make a configuration file of information about the package, and it builds
The last solution is to have the groups work together to make sure all packages have the same set of metainformation (more than is needed for any given package system), so that cross-platform package installs become possible. In practice, I don't see this scaling across versions, as package management systems evolve.
One more thing to bear in mind is the perspective of the author of the article -- he says he runs Slackware, and builds most packages from source (something I've stopped doing maybe 3-5 years ago). Slackware's package management tools are very basic, manual, and crude. That gives a very different attitude towards package management than someone running a distribution like Red Hat, which has a much heavier-weight, more technologically-advanced, but somewhat fragile, somewhat inflexible package management system, or a user of Debian, which has a state-of-the-art ubermaintainable, uberupgradeable package management system, but that primarily relies on grabbing packages from one (or a small number) of sources. I apologize about the stereotypes in this paragraph -- they're not entirely true, but the package management systems differ a lot (more than most people realize, if you've ever tried to build the packages), and I'm just trying to make people aware that users of each of them will have a very different world view, and it's important to keep that in mind when reading these articles.
Did you even READ the name of the project I referenced? It's called Autopackage. It takes care of that for you.
True story.
Let's see if we can actually go for six months without somebody announcing Yet Another Binary Package Management System or Meta-System. That would actually be newsworthy.
The amount of time and money that's been wasted on this problem for over twenty years in the unix world is just mind-boggling. We really do not need to reinvent this wheel again.
News for Nerds. Stuff that Matters? Like hell.
Yes, I know, this might be considered offtopic, but...
:)
If we get KDE and Gnome work together, then we might also, eventually get an installer too!!!
PLEASE!!!
Let KDE 4.0 and Gnome 3.0 be the same!!!
Why hasn't anyone developed a system that, from the End-user perspective, works similarly to MSI installations (which work very well). Point, click, next next next. In principal, DEBS/RPMs work similarly to MSIs, but the installation isn't as obvious a procedure to end-users.
And for that matter, why not make the installer intelligent about the distro? Use a single package/installer, but that includes all sorts of scripting information about installation in variosu circumstances. The installer checks to see if it's on RH9, and if so it puts files where RH9 expects them, editing any configurations and making RPM database entries as necessary. If it's on Debian, it takes the appropriate measures there. And so forth.
Why do we see such absurd dependencies that don't seem to happen in the windows and mac worlds? Install a new version of a KDE app, and you need the latest minor revision to the core KDE libs, which in turn requires a minor upgrade to the font server, etc. In the windows world, occasionally you need to update something big like DirectX to install a latest-and-greatest app, but even then the dependencies are often packaged with the app itself. Why isn't this practice more common in Linux/Unix (not counting Mac OS X)? I undestand that many of these apps are under CONSTANT quick-release development and are often tied to bleeding-edge versions of their libs, but why aren't major releases at least more dependency-friendly? Installing an app can be a real pain in the ass even with something like apt, if you don't have the dependencies in the repositories you've defined. And adding new respositories isn't exacly grandma-friendly.
It is when used on Slackware. Slackware packages add the metadata in a specially named file in the archive, very much like a Java JAR manifest. (A JAR is bascially just a .zip with a manifest.)
When you use pkgtool to install from the tgz file, the package database is updated with info about the package that you just installed. It can also check for dependencies, etc.
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
Standards are not a price, they are an investment. I use standard XHTML, CSS, and SVG in my web design because I care about the future of the web. Besides, if a standard is well-designed (like W3C recommendations tend to be), it actually makes development and maintenance easier. Anyone who has migrated from HTML 3 (or some nonstandard IE/Netscape HackML) to HTML 4 or XHTML with CSS knows what a pleasure it is to work with modern hypertext (and probably also has an abiding and bitter hatred for IE). The same could be true of package installation in Linux if the standard is well-designed.
A package is a file that contains information needed to install and uninstall a program. They are similar to MSI files, but have a number of advantages, mostly stemming from the fact that free software is, well, free, and so you can get it without buying it. Proprietary software comes on CDs, whereas free comes over the Internet. Upgrading free software is very "light weight" whereas upgrading proprietary software is usually very "heavy weight." This gives a different distribution model.
.dll files you don't need, weird interdependencies, and the system gets slower, more bloated, etc. This doesn't happen on Debian -- I installed my box maybe 3 or 4 years ago, and it's identical in functionality to if I installed it yesterday. Package management, well implemented, buys you that. You never reinstall the overall system, and upgrades are well-managed and don't break things.
.rpm even longer).
This has several effects. If I distribute a nonfree 10MB program UberTool, that requires the nonfree 20MB MegaLib, I'd better distribute MegaLib with UberTool. If both are free, I can distribute them seperately -- if the user already has MegaLib, he'll just install UberTool.deb. If he doesn't, the package management system will know where to grab MegaLib from, will download MegaLib.deb, and install it.
Furthermore, if I'm going from Office 97 to Office 2000, it's because I bought money on a CD, and I'm running an installer. In the free software world, upgrades are no-brainers, since they cost no money, and most free software programs are a smooth evolution, rather than major versions every several years. As a result, I'll generally be running the latest version of my office suite (as well as every other little utility on my system), and it is convenient to be able to do the upgrades all in one step (apt-get upgrade; apt-get update will grab all packages with newer versions, and install them, cleanly removing the previous ones). Most people never reinstall Debian -- I know installs from '96 that are still running today, at the latest versions, and there are almost certainly ones from before. I don't know of anyone who went from DOS/Windows 3.1 through Windows XP with just upgrades, and without a reinstall.
The next thing is Windows has a problem of bit rot. If you leave a Windows system without reinstalling the whole thing, adding and removing programs, etc. crap builds up. You get all sorts of registry keys you don't need,
The other place package management helps is in centrally-maintained networks. You can install the same package, with the same configuration settings, very easily from a centralized location.
So package management is, in effect, a fancy way to install and uninstall files. However, the fanciness buys you a lot. The new Windows installer is a form of package management, and gives some of the same advantages, although it's not yet as mature as the GNU/Linux ones (.deb has been around since at least '95, and
Looking at this from a newbie's point of view, is this really such a great idea? I mean, at face value, the idea of us living in a utopia where all the differing packaging standards are compatible is nice, but how many "green" Linux users would even understand what a difference is? They would see themselves as using Linux as opposed to Windows, and not abc's Linux as opposed to xyz's Linux or Windows...
.rpm standard, but can you imagine trying to install a Mandrake RPM with a *lot* of deps on a Red Hat system?
Total package compatibility would most likely lead to someone using Red Hat trying to install a debian package, and then getting frustrated, confused and pissed off with the inevitable failure due to the entirely different internals of Debian and Red Hat.
Unfortunately, it is a sad fact of life that Linux distros are deviating from the once common base they shared. An example of this is Mandrake - I used to use Mandrake around versions 6 and 7 and quite often installed Red Hat rpms successfully. However, as those crazy French spend more time tweaking Mandrake in weird and wonderful ways, it becomes further and further removed from Red Hat. Sure, they both use the
All of this leads me to conclude that perhaps rather than concentrating on unifying packaging, we should instead focus on making incompatible packaging systems for each major distro. IMHO, it would be much easier for a newbie to distinguish between what will and won't work if they were guaranteed that an rpm would ALWAYS work on Red Hat, and some other kind of package (MPM?) would ALWAYS work on Mandrake....
Sunday you're Thinking Different, Monday you're a huge tool, paying too much and waiting to think like everyone else.
zapp's comment below is good, but I feel the need to add some things.
There are still PLENTY of Windows applications that don't use Add/Remove programs. You have to find their uninstaller, if they have one. This is the same as downloading a tar.gz with the source and hoping it has a "make uninstall" target. However, free software is available to track packages you compile and the files they install. Software is probably available to help uninstall stuff under Windows too.
With Debian, I can find out all of the files a package has installed. I can re-run the initial configuration. When I uninstall the application, it won't remove the config files in case I re-install later (unless I tell it to "purge"). I can query the package database and find out what the package is actually supposed to do, which is often a problem for me on Windows systems which are not my own ("What is this?" "I don't know!")
Additionally, a good package management front-end like APT, coupled with well-organized packages, makes maintenance a breeze. I can update every application with two commands*. Libraries are only installed if I need them, and it's safe to share libraries because programs won't be trying to install incompatible versions of them (if they did, the package manager would notice and tell me).
So yes, installation programs like MSI files are simpler, but I wouldn't say they were easier.
* Except for the source-installed apps, of course, but those are a) not packages, and b) few and far between on a Debian system.
WMBC freeform/independent online radio.
...to manage my package.
How about a .app bundle that you drag to your /Applications folder? How about letting it contain binaries for multiple platforms / CPU architectures. Oh, wait, NeXT/OPEN/GNUStep and OS X have had these for years.
I am TheRaven on Soylent News
Which is why I'm working on getting gentoo portage going for Solaris. Portaris!
If you feel you habe some ideas that could help with this mini project, feel free to join in!
Too much trust is placed in the installation program getting it right, and no built-in way is available to check if dependencies are broken.
You can ding the different distributions -- and quite rightly -- for package problems though in comparison most of them are dreams when stacked up against Redmond's latest offering.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
What I'd like to see is more distro vendors moving to a metapackaging system like APT, and then the following rule applied throughout:
Either your package uses packages from some standard repository (Linux standard base, anyone?)
OR
You will provide all needed packages that are NOT in that standard set in your APT repository.
So if I provide Foo.1.2.3, and it requires Narf.2.4.pentium, and the standard repository is providing Narf.2.3, then I must provide Narf.2.4.pentium on my site.
Of course, I would also pimpslap anybody who actually depended upon Narf.2.4. pentium as opposed to simply Narf.2.4.
And to address the tweakophillia of the Gentoo types - what about a program that could be run from a cron job that would examine all recently installed packages, pull the source packages, rebuild them with the locally provided options, and upgrade them? Thus, I could *quickly* install Poit.9.1, and then tonight my machine would pull Poit.9.1.src, build it with "-Os -march=athlon-xp -mcpu=athlon-xp -mfpmath=sse,387", and install it.
www.eFax.com are spammers
As usual I'll come out with my Gentoo Zealotry but I'd like to deflect some of the problems I'm seeing mentioned here.
Gentoo is a Linux distribution largely centric to the Portage package manager (there are other features of Gentoo, but Portage is by far the most conspicuous)
Portage is a package manager loosely inspired by FreeBSD's ports system. Portage maintains a global software configuration file called make.conf. Make.conf holds meta-configuration settings about your system. As Portage builds all programs from source for your machine, make.conf is the place where you describe your machine to Portage. make.conf also holds a collection of use flags. Use flags are global binary switches. They have a default value if they are unspecified, and if you include a Use flag (ie USE="java") then it turns that flag on, and if you include -flag, (ie USE="-java") then it explicitly will not use that feature which is globally recognized by Gentoo.
I see complaints that emerge VI tried to build X and thus portage is "smarter" than you as a sysadmin. This is patently false and ignorant. Portage lets you do your job as a sysadmin once and then never have to worry about doing it again. If you do not want X on a machine then you need merely put "-X" in your use flags.
It puts control in your hands. If you want an application built to support certain things you can have it. If you do not want to support other things explicitly it will do that. It defaults tod doing what's sensible for most people who use Linux casually. If you aren't a casual user, spend a week or so getting familiar with portage and it's configuration. emerge is an incredibly potent tool. All of my systems are patched automatically every day, from source, with the configuration I have specified for that system. My binaries are all built with -march for the CPU, and -Os. And I've never once had any of my systems have a failure caused by misconfigured dependencies. They stay up to date and I don't have to worry about it.
If you want to do all your dependency checking yourself, you're welcome to. However there's a good solution that takes care of all of the issues revolving around this available, freely, to the world. Click here to find out more about it.
"Give away the stone, let the oceans take and transmutate this cold and faded anchor." - Maynard James Keenan
I was a long time Debian user, and I've "switched" to Gentoo. The primary reason I feel the ports/portage system is better is that I am not forced to install packages that have dependencies on other packages I don't need. For example, take gaim. In Debian, gaim has a dependency on NAS (Network Audio System), so I'm forced to install it. I don't need NAS. I don't want to install NAS. Gentoo has a USE flag that allows me to declare that I don't want anything to use NAS.
.deb. Say a new release of your favorite software comes out, but the package maintainer hasn't gotten around to packaging it. In Gentoo, in most cases, you simply copy the old ebuild file, and possibly tweak the version number. You don't have to download, compile, and package it seperately, as you'd have to do in Debian.
Also, it is pretty easy to make a custom "ebuild" file (which is a shell script) in Gentoo, and relatively difficult to create a new
There is also a lot less political activity in Gentoo, and they seem to Get Things Done.
Of all of the distributions I've used (Slackware (Walnut Creek '96 through 8.0), RedHat (5.1, 5.2, 6.0), SuSE (6.# through 7.0) and Debian (2.2 - Current Unstable)) I've found Debian's apt+dpkg combination to be the best built. It doesn't matter if I used Progeny, Storm, Knoppix, or any particular version of Debian Proper, I was always able to specify source servers and update the system. I was able to add third-party servers without much issue. The system just worked. RPM in the two distributions that I've experienced with it was a pain. It was hard to meet dependencies even with a particular package built for a particular distribution, and I ended up chasing my tail more than administering the box.
Of course, I liked Slackware due to the lack of general advanced packaging, since I didn't end up breaking a package management system with third party compiled-from-source software.
Do not look into laser with remaining eye.
People started calling them "Jock Straps" and we all know that a geek is no jock - so it was either Geek Strap or package manager...
From excellent karma to terible karma with a single +5 funny post...
Whoa, slow down. That's not right at all. Firstly, some RPMs are compatible across distributions, but not all - and it's basically hit and miss.
The linker fixup problems are one issue yes, but to be honest these occur rarely, especially once you start stripping unnecessary DT_NEEDED entries from your binary (unnecessary -lfoo options).
Eventually we'll need to change it to be more like how Windows does it, but it's not a high priority. Fixing build tools to not dump piles of bogus (in the case of recent toolchains) -lfoo options on the compiler is a more important issue, but I have no idea how to fix this in a general way. Possibly extensions to pkg-config would need to be made, certainly this is something that will require large-scale changes to peoples build systems.
I'm hoping that when autopackage is released and stable, it'll be so fantastically popular that it will motivate people to fix these myriad binary portability issues in their apps (and none of them are unsolvable or inherent in the way Linux works). We're writing a guidebook to help people do this, but it's not really released yet.
Java webstart is a complete solution to the packaging mess. develop with java, one click secure install, update and uninstall.
In other words, there should not be any "pre-install" or "post-install" or "during-install" scripts inside packages.
Packages should contain data. That's it. Leave all the executable work to the package manager, like dependency checking, startup scripts, etc.
Letting packages run its own stuffs during installation is the root of all issues associated with uninstalls.
Does anyone else see what's happening?
Too many package formats, too many window managers, too many GUI toolkits, too many desktop environments, too many Linux distributions, etc, etc.
I like choice, I really do, but this is madness. Not only is a great deal of time used to create competing software (Kword, Abiword, Open-Office) but now we're creating more work for ourselves by trying to integrate it all (packages managers, RedHat trying to unify GNOME and KDE, etc). Wow, this can't be good.
How is all of this going to compete with entities that have a more focused approach? I believe the only reason why anything has gotten done at all is because there's just so damn many people working on things. This causes serious talent dilution though. Things are nowhere near as good as they could be (or could have been).
This is quite disturbing.
It's interesting to note the things where this hasn't happened. Just try to create a competing standard to HTML, XML, SQL, or OpenGL (note that I'm talking Linux/FreeBSD, etc, not Windows). Not that people don't try but they never gain momentum. I have to think if there was an ANSI, ISO, or whatever standard desktop evironment then that would help. I seriously doubt something like that could be done in a reasonable time, I'm just saying it might help.
The ratio of people to cake is too big
I've not read the article since it won't freakin' load, but from the summary description I really fail to see how a new package manager will solve anything.
** Problems
- Package format compatability.
Generating software packages for rpm, deb, tgz, BSD ports, etc. is a major annoyance to software developers and package maintainers. The proposed system seems to solve this by supporting the 'big three' in one package manager. A single package system is the solution to this problem, not a new package mangler. I'm sure there are many proposed packaging systems out there that want to solve this exact problem, and the author's time might be better spent by adding support for the most promising system to apt or yum rather than taking what appears to me to be the wrong approach.
I don't know about other distributions, but Debian solves this problem rather nicely by allowing you to install rpm. There's also the alien utility, which will convert to or from deb, rpm, and tgz. Some would say that this is not ideal, but its far simpler than throwing volumes of standards and megabytes of scaffolding at the problem. "Keep it simple, but not simpler than it needs to be." Alien is as simple as elegance permits.
- Cross-distribution library compatability.
This problem will only be solved if distribution maintainers make a conscious effort to do so. I can assure you that this will never happen, and native-code binary packages will never, ever, ever fit the 'build once, run anywhere' model, even if 'anywhere' means a different distribution on the same platform. A new package manager will not make it any easier for me to install Mandrake's KDE 3.2 packages on my Debian or Fedora boxen.
- Cross-package-format dependency resolution.
About the only thing this idea would help with is satisfying package dependencies across package formats. E.g., libA, an rpm, depends on libB, which is only available as a deb. Assuming the the libraries in the rpm and the deb will install and link nicely, this idea would provide a package manager that would know how to do just that. But I can see no benefit to wanting to do this sort of thing in the first place, and I would suggest that it would only complicate systems management.
- Systems like FreeBSD port and Portage?
This manager works on the most popular systems. What about more esoteric package managers? Shouldn't it support them, too? Someone's bound to ask. In this regard, the system wouldn't be promoting standardization and would be duplicating the work of many distributions, probably poorly since attention (and design of the APIs used internally by the manager) has to be spread over many package formats instead of one. Again, a real solution is deciding on a single package system to use, not creating a tentacled, five-ton beast that will crush you to death when it tries to sit on your lap.
- The Simpsons did it! I mean, apt did it!
There are versions of apt for rpm and deb. They regrettably seem to be mutually exclusive, but the point is apt covers up many ugly parts of any packaging system via automation, and it supports two of the three package formats attributed to the author's idea. And since 99% of the time there is no reason to install packages of differing formats on the same system, it doesn't matter that apt for rpm and deb are mutually exclusive.
** Conclusion
Now that the site is back, I see that all this guy seems to want to do is write a silly GUI tool that lets you install packages of arbitrary formats by clicking a few times and that will run on the popular systems so that users will feel at home on different distributions thanks to a consistent GUI. Oh well, I wish you luck guy. I think this is a worthy endeavor insofar as end-users and the much-hyped "Linux Desktop" are concerned.
-Nick
You've had XP installed for a year. Charming. That's one version of the OS. Wait for Longhorn to come out, and then whatever comes after that, and see if you can go through all the upgrades without reinstalling. Until then, you can't draw any conclusions.
One year is a lot of time by Windows 95 standards for not having to reinstall. In contrast, by Debian standards, you go through many, many major revisions of the core OS, and then don't have to upgrade.
I would also question how many major revisions of applications you could have gone through in one year. Under Debian, I have gone through hundreds or thousands of programs, from pre-alpha to beta to release to several major versions ahead, and never had a problem, in many long years of use. One year is nothing. Wait for the next version of XP, 3 more versions of Office, and a couple of Internet Explorer, keeping a couple of old applications incompatible with the new DLLs, and then tell me Windows doesn't have bit rot. Keeping the same version of an OS installed for a year says nothing about bit rot.
Here's a similar package funded by a dutch institution:
A-A-P
DNA is the ultimate spaghetti code.
This is exactly what should be done, but people here are too brainwashed to admit that perhaps some features of Posix should be changed.
/proc/self/exe and use it to setenv LD_LIBRARY_PATH, and locate the actual executable. It then exec's the actual executable. In our case the wrapper also makes sure argv[0] is a clean full path name so the actual executable can use it to locate data files and plugins, you could also put this function in the main program if you wanted.
It is possible to fake this, we do it with our commercial Linux software, and it is obvious that other commercial software does this:
*All* files for your software are dumped into a single directory, so installation and removal is trivial (this is similar to OS/X App directories). In that directory is a single "wrapper" executable, usually with the name of your program, and only dependent on glibc. The main thing this program does is read
We then install Gnome and KDE shortcuts on their start menus directly pointing at the full pathname of the executable. Anybody who wants to run it from a shell has to type the full path or symbolically link it themselves into a directory on their path. Deleting our software leaves these start menu items and any symbolic links pointing at nothing, which as far as I can tell is not a real problem.
Intelligent users can easily peek into our directories and see that we ship libtcl and some others in an attempt to hide system differences. They can rename or remove these to better integrate the software into their system. But at least it works, first time, for any users.
I would like to see Linux altered to handle this cleanly, by adding direct support for "app directories". Unlike OS/X, I think they should be named with no extension. The rules are simple: if the user tries to run "foo" and it is a directory, it tries to run "foo/foo" after first adding foo to the LD_LIBRARY_PATH and after fixing up argv[0] to be the full expanded path to foo, and possibly other fixes for stupid Posix rules. This would get rid of 99% of the "install" headaches.
On Windows, the linker records which DLL a symbol comes from and you can explicitly specify it in the source/header files using some simple language extensions. On Linux, that isn't done, and worse ELF specifies unscoped symbol fixup semantics.
To rephrase the original question: if libA1.so is linked against foo_func() in libA2.so, and libB1.so depends on foo_func() in libB2.so, and binary Z links against libA1 and libB1, then the results will not be what you expect. Both libA1 and libB1 will be linked to the foo_func() in libA1, because that came first in the load order.
This causes problems when different parts of the program use different versions of the same library - they may be independent parts of the code but the wires get crossed inside ld.so and things go boom.
It'll need to be fixed at some point. Using the ELF grouping extension in Solaris seems to make sense. Somebody just needs to write the code and (this is the hard part) get it accepted upstream.