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)."
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.
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!
My main recommendation for Gentoo...
Let's say I update my portage tree, and then I want to upgrade a package, like GAIM, for instance. GAIM's dependencies are GTK and a bunch of other stuff. When I try to upgrade my version of GAIM and there happens to be a better version of GTK available, Portage will upgrade GTK first, regardless of whether you actually need the very latest GTK to run GAIM. I'd rather see Portage know what the minimum version a dependency has to be in order to get a program running. As far as I know, it'll just upgrade everything in the dep tree.
Unless I'm mistaken, at least. I've been using Gentoo for a while now, and for the most part I just do a "emerge -u world", which takes care of me pretty nicely. It just takes a while.
---
"Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of"-TMBG
Essentially there would be some glue between the package management system, the "configurator", and the actual config file.
Sunny Dubey
Funny, all I ever see is Gentoo bashing. Are we reading the same sladhdot?
philcrissman.com.
Not true. Red Hat's up2date supports apt repositories and the dpkg format is getting GPG signature/hash checking. From discussion late in the Fedora Core 1 beta stage it seemed that there is internal pressue to include apt in the core distro at Red Hat. Those are big changes, I think. I stopped reading the article since it's getting slashdotted, but it the author[s] can implement a single database that tracks installation by RPM, deb, and tgz, then I'd wager those features will be added to RPM and dpkg down the line. I honestly can't see either Debian or RedHat jumping ship to a new system, but they both borrow features from each other, so why not from this too?
Sounds like everyone is looking for something like the FreeBSD ports collection.
alien
You can't make a universal package manager because the various bulk packagers organize their work differently. If there was only one way to do things, it could work, but there are many ways. You can't just grab an arbitrary package from Mandrake and expect it to work with RedHat and SuSe, and they all three use rpm's. Yes you can technically convert them, but the philosophy behind the distro is the deciding factor as to how useful any given package might be for anything other than the simplest cases.
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.
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
Do you have any more information regarding that? Everytime I've asked on #debian I get very vague answers. Usually the argument is that all the package maintainers and contributors would need to send in their keys and sign all of the packages they contribute which would require a lot of effort. Given the recent security issues with trojans I think that this would be well worth the effort.
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
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.
FC1 works fairly well over here. But you are right, there is no way to resume and that's a major problem that should be addressed immediately. Also, I quickly learned not to use the sources provided by the default install, and instead spent 5 minutes searching and found an alt set of sources for both up2date and yum. And which config utilities were you expecting that you didn't find in FC1?
The only sensible way to work is with source patching, it is far easier to download smallish source patches and compile in situ than to solve the stupid issues of large binary downloads. Most end users would neither know nor care how it worked, as long as it worked. Most PCs are more than capable of supporting the C compiler, or whatever is needed in each case. A source patching system can be made to work transparently to the user, anything involving excessively large downloads can not be made to work. It is as simple as that.
Not a bad idea, in theory. I would like to see a working implementation before I say one way or another if it's the best thing.
This issue is one of the few serious problems that are hindering the uptake of Linux on the desktop.
Actually, the only thing that is blocking linux's acceptance in the desktop world is the lack of MS office. Seriously.
The other major one I have already referred to, badly broken configuration utilities.
Again, I do not understand this. Linux has some awsome configuration utilities, certainly more than windows, so this can not be barring it's acceptance into the desktop world. What utilities are you missing?
Mod me down with all of your hatred and your journey towards the dark side will be complete!
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
Secondly, linux applications are built around a wide range of supporting libraries, few of which are standard to all distributions - this means either huge packages, or a dependency resolution mechanism, like apt.
You are right about that. What i was wondering is how huge a package will be if it included some of the more uncommon libs. I understand it is a fine balance, but i just feel that many applications could do a better job. Take xmltv for an example. It depends on some 15 perl modules, which the user has to install from CPAN. Last i tried to install xmltv one of the libs was broken and wouldn't install, which means i still don't have xmltv.
A perl module is just a few Kb and the only excude not to include it is lazyness. I understand the developers reason not to include the libs though. Most of the oss developers work in their spare time, and are motived primarily by their own needs and can actually completely disregard others users needs.
"Nobody really checks their email any more. They just delete their spam"
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
I really think it's a language issue. CPAN doesn't have any problems like this, because Perl allows you to change your interface without breaking compatibility. I have never ever had a CPAN module fail to install.
Find free books.