Installation and package management systems
 

Hi.

I need to create installation packages as part of an automated build system (under RedHat Linux). While using RPMs I encountered an issue with reference counting. Namely, that RPM doesn't support them.

Let's say you installed two packages that have some shared resource (the same file). The requirement is, that if you uninstall one of them, the file should not be removed, since it is used by another installation (i.e. reference counter should be checked). RPM doesn't even have such notion, and when removing such packages, it will erase shared files.

Does anyone know any alternatives to RPM (which can be used under RedHat), that implement reference counting and can be included as a part of automated build? (For example, WiX installer under Windows has an XML notation from which the package is compiled).

Also, is Debian package management any better than RedHat's? May be there are reference counters there? And if so, is it portable to RedHat?

What you are referring to is dependencies. Rpm is a very basic tool (and very powerful) and does not consider dependencies(was never meant to). If you are using straight RH (and not RHEL) you should stop. Straight RH hit its EOL (End Of Life) in 2003. Now RHEL is another matter. RHEL (up to RHEL4) used up2date to handle installing packages(dependencies). up2date is a (more or less) front end for rpm that handles dependencies(sort of). yum is the package manager for RHEL5 (and newer) as well as the "standard" package manager for Fedora (going back to FC4 or further, F10 is current). There is also the smart package manager (usually smart and smart-gui) that is available across many distros (rpm and deb)(smart does not depend on yum). Yumex (yum extender) is a graphical front end for yum(therefore it is limited by yum).

I can't comment on package management systems from a developer perspective, as I'm just an average end-user. However, I've had much better success with Debian-based distributions for their package management. My brief experience with Fedora put me off RPM-based distributions permanently. However, I'm currently downloading Slackware 12.2, with the intention of forsaking package-management tools altogether.

well slackpkg is a very stable program if the dependencies are in the repository it will load them but it will never uninstall unless you tell it to. if the dependencies are not there it will still load it in and tell you hey your missing this stuff. or you can use it to build custom package. or build your own. slackware is a developers work horse so it has 95 percent of the tools on a full install. the package tool in slackware is called pkgtool and runs a nice interface in a terminal.

I'm using RHEL4.

If RPM doesn't resolve file level dependencies (I'm not talking about package level dependencies), all higher level wrappers over it might only provide workaround for this issue. This seems to be an unhealthy approach. Why shouldn't the base tool itself intended to take file level dependencies in account? (Microsoft did it in MSI/Installer service for example).

Thanks I'll take a look. Do any of them resolve file level dependencies?

Yes, both yum and smart take into account whether something else depends on the given file (and warns you) before it removes it. I really would not hold up MS as an example of how to do things, particularly considering their security record.

I can not understand why one package should install /path/to/someresource and another would as well (apart from upgrades). Shared resource ownership to me sounds like a packagers error. Maybe you could give us a Real Life example so we see it isn't? .spec file excerpts from any official packages would do.

unSpawn: Let say in your distributed corporate development you have to develop a set of some programs/tools (for example web services, or other tools) that rely on some common platform (core components). So when you install some subset of these tools, they have to install their core base too (in order to be functional). You can install the common core as a separate package of course, but this is not practical, especially when you deal with a client who doesn't want to install 20 different packages etc. in order to install some single functionality. So different tools from that set will drag with them the same core.

So the expected behavior will be, that when you install several tools and uninstall some of them, the core components should not be removed until something is still using them.

Everything has some deficiencies, but at least MSI has a straightforward reference counting resolution on file level.

Yes! Stick to the design! Follow whatever procedures you got!

So far so good...


So to placate (or keep) one customer you are going to jump through burning hoops 'til you singe, forsake all functional designs, tear up any safety nets you've got and bend a well-operating package management system out of true... and that while, by the looks of it, isn't even a technical problem! The argument of objecting to installing n packages looks decidedly weak to me (not that I *don't* understand you just gotta have this though).


Apart from workarounds like ( rollback; --justdb; rpm2cpio|cpio ), as far as I know a resource should reside in one RPM. So instead I would think about redefining packages and dependencies (but then again what do I know. I've only helped a few people building packages and I only craft a few packages from scratch a year). I somewhat doubt there's a more mature and evolved package manager around that off the shelf truly exceeds what RPM offers already...

hello sherml this is a linux forum if you feel that you want some enslaved software go ahead and use it. Nice thing about linux you can change it shape it --> YOU CAN.<-- Please try to Keep MS out of the picture. So go re Write some drivers for Windows and make a custom system but when the software crashes as some do just open up the windows source code and figure it out.!@#$%^&*()_++++!@#$%^&*()_+!@#$%^&*()_+|!@#$%^&*()_+++

BTW, in practice it's not even possible without use of --force as it will make RPM show a clear packagers beware warning:
I really, really vote for redesigning (including virtual) packages.

If something made by MS can be considered superior to Linux alternative I don't see any reason to keep it out of the picture and not to ask how to achieve it on Linux too. Any kind of improvement is possible if one doesn't sleep and understands the evolution of system designs. May be some prefer to stick to one and the same design forever. But no one will guarantee it'll remain superior to everything else forever too.

It sometimes boils down to creating a separate package for every shared object (library). May be it is arguable, but I think such approach is not too practical. If at least these packages can be merged (included) into one another, it could be a different situation.

Look, I don't know where the assumption of creating packages for every .so comes from and I don't know what your level of RPM-fu is but until you post a RL example this all really doesn't help to supply a solution. So please post something tangible. Unless you don't really want a solution, that is...

My experience with trying to get Slackware to do dependency resolution has not been very successful. I've tried swaret, slackpkg, NetBSD's pkgsrc and a few other options which slip my mind. They either failed completely or messed with my system too much and made it unstable. I think if you're going to do Slackware, then it's kind of missing the point anyway. Either compile from source or install from .tgz files.

The best dependency checking I have found is typing "./configure" and reading the error messages. In second place, I would say, is the Debian/Ubuntu route.

I had hoped to be able to say wonderful things about the FreeBSD/DesktopBSD ports system. The idea is great, getting a tight, efficient, source-based operating system while letting the compiler download its own dependencies. In reality, I found it to be painfully slow, successful only around 60-70% of the time, and it eventually broke my system completely with little or no guidance as to what had gone wrong. I don't know if they give the ports system a version number, but I think they would struggle to justify calling it v0.1. They need to stall adding any more software to the repository and seriously tighten up everything that's already there, if BSD is to achieve what I'm sure it can, becoming a viable desktop solution.

In any case, I've made the leap now and come "back to Slack". And I'm planning on sticking around.