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.
Hm, at first this sounded like a good idea, but with Perens involved you probably won't be able to install any qt related software with it.
Anyone got a mirror?
-Tut
Health-Hack.com
Can someone provide mirror or text here.
I would jump on the Portage bandwagon, and continue with that effort. There already a couple projects working toward cross-distro compatibily, for instance Emerde.
Portage has the ability to install RPM's on a Gentoo system. While not as easy as emerging from the source, it has a very wide horizon ahead of it. I am not sure aobut Portage using DEB's though.
Well, for conversion from RPM to DEB (and supposedly the other way around), alien has worked quite well for me (apt-get install alien). Thus far I've managed to convert+install several RPM's that otherwise would not have worked very well on my debian system.
It doesn't have any metadata like what other packages this package requires, etc. Its fine
for what it is but it ain't no package format.
Essentially there would be some glue between the package management system, the "configurator", and the actual config file.
Sunny Dubey
He asked, "Do you use the penguin one or the lizard one?"
Uh yeah, its called XUL
Pretty cool eh?Package management is broken badly enough as it is in any single distro that adheres to one single packagement management solution. I don't see how adding more broken methods is going to help matters. RPM hell is bad enough. Let alone inconsistancies between RPM hell, .deb hell, and tgz/source which doesn't even check to make sure it's sane to install a package.
Sounds like everyone is looking for something like the FreeBSD ports collection.
How about: An exe file named "setup" or "install"? Then you double-click on it, a wizard prompt, just clik OK about 3 times and done!.
Is that hard?
DNA in your Linux: DNALinux
just wear an atheletic supporter and forget...oh. This was under the linux topic. nevermind.
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
Hey, a Linux idea that actually makes sense. Standarize everything! the MICROSOFT way!
Me and my friend had a long discussion about this last night. My conclusion was that as long as linux has 5 competing packaging formats. FreeBSD is a perfect example of a community united.
however i'm under the firm belief that linux will always be a fragmented mess, and the only reason BSD is so united is because of it's commercial liscensing.
a man can dream though. i'd like to stop having to worry about redhat-rpms, mandrake-rpms, debs, ebuilds, and tar.gzs and boy am i sick of compiling from source.
- tristan
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.
Oh yeah and the only application that supports it is some super cool framework on SourceForge in 0.01 Beta.
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!!!
I don't know much about this issue, but I keep wondering, why can't somebody make things easy in Linux as in Mac OS X? Do we really have to install all the junk in different folders, bin, sbin, user, blah blah.
I would be so much nicer to have a program selfcontained in a folder and than just move it around, uninstall it just by moving the folder to trash can, etc. Don't know how this is done in OS X but I guess it can be done in Linux too.
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.
I've never been terribly concerned about incompatible package foramts, as long as source is available. The common system is that everything managed by the package manager goes into /usr, and everything I build myself goes into /usr/local.
/etc/init.d, but that's about it.
Once in a while I have to copy something manually into
Of course, it helps that for almost anything I want to install, my distribution includes it or at least includes the dependencies.
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.
duh
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.
Yeah, because the size of a package will surely affect the code of the application...
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
The desktop app is synaptic, works with Debian and Redhat for certain, haven't yet tried with SuSE, etc.
Good packaging actually causes these things to shrink because you don't need to duplicate dependencies and it's easier to share libraries.
Michael
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.
If any of you have bought games in the past few years you've probably used Loki Setup. Why wouldn't we use a program like this for simple software installation and an advanced 'package manager' for system updates. I think the problem is that we use overly complicated package managers for EVERYTHING when individual downloads don't need it.
Quack, quack.
I'd like to see autoconf / automake extended to fit in with this, so that when you build a project from source using these tools they set up the Makefile to produce a package, either as RPM or DEB, of all the files to be installed. In theory autoconf does all the dependency checking for required libraries and headers anyway, so the dependencies shouldn't be a major problem: probably even the name and version of the package could be figured out automagically from the LSB description.
.spec files.
This would make it so much easier to integrate packages for which no RPM or DEB exists into your system: I don't like stow and it's unreasonable to expect everyone for whom this functionality would be useful to be able to write
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
I actually pondered putting a or tag on the post, but I then decided against it. Perhaps I should have.
If anything it's time for the Open Source community to "Embrace and Lag Behind" yet another Mirosoft innovation.
Microsoft Research has a new product in beta named "Microsoft Visual CAB++.NET" that will provide for all your packaging needs. Call 1-800-SUCK-ASS for the 411.
Chinpokomon! You Americans with your massive, gargantuan penis! Keeping world safe from Iraqi WMD!
The binary diff would look for the existing files matching some checksum and patch them up with the changes rather than uninstalling replacing old files with substantially identical new ones.
The package format is only the first and probably most shallow problem in trying to use cross-distribution packages. A huge portion of package reliability and usability comes from a well managed set of package interdependencies. Managing those interdependencies is a major task for a single distro, let alone trying to handle the exponentially more complex dependencies sanely accros distros.
If you really want to solve the problem of cross-distro's, you need start at the other end. Define your own packaging standard which favors statically compiled dependencies. Then write or adapt tools to package the resulting statically linked binaries into different distro packaging formats. You can't just blindly statically link either. For some applications, you'll also have to solve device interface, and kernel interface issues across distro's and kernel versions and configurations too.
It really isn't about the package format
/usr/local is a nominal installation point only. In the real world, site requirements can be much more complex. Over the years, I've noticed that autoconf handles this situation very cleanly. It's the people building binary packages that seem to overlook the need for relocation.
Of course it is! A common package notation allows dependencies between software components to be detected precisely and automatically. It's only a step from there to have dependencies resolved automatically as well.
If two software components use two different package notations, you're forced to do figure out and resolve their interdependencies by hand. Supposing you could do it at all, what do you think the chances are that you'll do it identically twice in a row on the same system, let alone on a server room full of systems which are to be configured identically?
Of course you're right that the problem is not entirely solved merely by committing to a universal package format. Developers still have to take care to use its capabilities correctly. Dependencies have to be expressed accurately, for example.
I've also noticed that relocation is often not done properly in open source packages. I suspect this may be because many open source developers are not used to installing software at complex sites where different administrative groups maintain different sets of software at different points on different servers. The point is that
...to manage my package.
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!
the problem with rpm is it's success. when a half dozen distro's start using it a half dozen versions of any given package are developed... throw in rawhides and their ilk and suddenly package management becomes a nightmarek.
if you are going to use rpms stick to your vendor. it may suck being a slave to up2date but it beats the conflicts.
2 1337 4 u!
Loki's games have them too, but they tend to compile most of them into a big staticly-linked binary, leaving only the major ones like X for the user. Works fine for huge games when another couple of megs doesn't matter. Basically, if you build an executable static, it has almost no dependancies, but it's a huge file. If you build a file with dynamic linking, it'll create a tiny executable, but it relys on various libraries to run, and more than that, certain versions of those libraries.
The upside to this is that all the parts of a linux system can be developed simultaniously and independantly, and the result will still work.
Can you imagine KDE for example, being built staticly linked to all of the sound, video, encryption, math, etc. libraries that it needs to run? You could do that and release a nice installer on CD once a year, and then wait for the next release before you can upgrade ANYTHING on your system, because it's all one giant package.
In a distributed development system without central management, and without a product to ship to Babbages, many small packages are the only real solution.
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.
All these conversations about different package formats, dependency hell, et al. flies right over the heads of many Debian users. Many of us are usually surprised at the amount of problems other distros have when it comes down to packaging. Now before you mark me as a troll ponder this: It isn't the package format that needs revision its the maintaining of an entire repository of packages. This is why Debian users are surprised by all this, or possibly why some migrated to the distro to begin with. People need to stop worrying about what format there software comes from, but rather begin creating a universal set of dependencies and one congruent software repository. Until then only debian users will know the true joy in running apt-get update && apt-get upgrade.
transmission_err
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.
A lot of people have eluded to this, but I'm going to be the smart ass to say it straight out:
We need packaging/installation policy standards!
Imagine a centralized, yet somewhat distributed control, database over names of libraries/packages. The libraries name would not include version numbers or anything like that. In addition to this there's a standard scheme for naming packages, version numbers, etc.
Now, the bigger problem is not what installs where, rather what installs what. The policy standard for package management is not the format, the manager or whatever to use, but what each package should contain. I.e. a standardized policy regarding how much one is allowed to cram into a package. Of course they all need meta-information saying what they provide.
So if you have, e.g., a standardized policy of one package per lib and a naming scheme that is adopted by major distros... feel free to use whatever package management you want.
"So unmerciful is life, that everything afterwards is too late."
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.
Lots of these posts have mentioned that different distros use different packaging schemes and that there can also be problems with package names and dependancy locations (e.g. required .so files being in the wrong directory), but I haven't heard anybody mention the problem of binary compatability. Suppose I have program a.out which requires a.so and b.so to run. Now a.so also uses b.so, but a.so was compiled against b.so version 3 while a.out was compiled against b.so version 4. This will lead to problems as the loader will load only ONE version of the library and require both a.out and a.so to use the same version of b.so. This is why rpm's of the same program are not compatible accross different versions of the same distro! We'll never get out of the dependancy hell until somebody fixes this problem (e.g. Windows works the way you'd want). There's more info on this issue in the Autopackage FAQ if you're interested.
BTW: suppose I've got a.so version 3 on my machine and I go to install myprog. myprog requires a.so version 5. Upgrading a.so will require upgrading 500 other binaries on my system as they also depend on a.so version 3. As far as I can tell rpm doesn't want to let me install a.so version 5 (e.g. a.so.5) along side a.so.3 without using the --force option even though that would/should work in many instances and make an upgrade much easier. Am I missing something??
I have an idea that maybe will help fix things just a little:
Instead of treating all packages the same, make a seperation between libraries, daemons, servers, utilties, and desktop applications. Then you can have a global setting for the system that decides what kind of user is using the computer: desktop average joe, programmer/developer, server machine. Then you can manage packages much simpler.
Let's say that it's an average joe desktop box. In this case, libraries only need to be installed if 1 or more applications depend on them. just have the package system transparently manage this: if a new application is installed that depends on a library that isn't installed then also install the library. If an application is removed and there is a library which only that application depends on then remove the library. If two applications need 2 different versions of the same library then manage this smartly, and merge the libraries once the apps become compatible.
Right now, this "one package format fits all packages" approach limits us, and limits flexibility. The package manager should know more info, or "metadata", about each package installed so that it can manage things smarter.
peace
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...
I have been managing my own package for years now and I think, aside from the not being unwrapped frequently enough I have been doing a pretty good job on my own. I think the real development could be done in getting package's target audience to learn a thing or two on how to properly work the package.
Java webstart is a complete solution to the packaging mess. develop with java, one click secure install, update and uninstall.
*cough*ebuild*cough*
c'mon, it's not even offtopic this time!
The other package formats are nothing but trade-offs to lure Windows users.
With every Linux box having gcc, is there really any reason why apps have to be pre-compiled? Sure you can pre-comile stuff for an installation CD, but after that, it just makes sense to use an installation method like Gentoo's portage.
After all, this IS linux...
I've noticed that autoconf handles this situation very cleanly.
No, it doesn't.
All autoconf does is make it easy to change the hardcoded paths that will be compiled into the package at build time. Once the binaries are built, they have to go into the specified locataions, and the config files into theirs, etc. etc.
It's the people building binary packages that seem to overlook the need for relocation.
The underlying source code usually doesn't support relocation after it's built. There's nothing the package builders can do about it. Well, they can rewrite the source to support it, I suppose. That sounds like fun. And I can guarantee that it won't be tested properly, and it won't cover all the things that you want/need to do, and so you'll have to rebuild from source anyway. People who run large complicated installations that need custom layouts are going to have to accept the fact that their layouts are just that, custom, and are not, generally, going to be supported by the statndard package system.
Imagine - "Linux runs everything."
I'm not implying there are dozens of programs solely for Windows that Linux users are dying for, but some people are married to one app or the other, and that keeps them from trying Linux.
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.
One of the things that continually stumps me is why can't source trees (from CVS, tar.gz, where ever) compile out and create an installable package? Making a distributable package has always been a secondary step instead of an integral part of the installation build.
What I want to see more of is "tree building". Once again from some distribution system (CVS, tar.gz, etc.) the code can sit. When a release is pushed out you do an update/merge and rebuild. This ties into the previous paragraph where you can just recompile the packages and upgrade them for tight management.
Package management works now if you don't want to deal with source code. The moment you start trying to build your own source for system tools things start to blurr. This is how Linux systems now accumulate cruft which neither the package system or compiling can handle. If both were some how brought closer together there might be hope to keeping it sane for a bit longer.
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
Ok, what I never understood with binary packages is why not include all the precompiled dependencies right there in the package, install them all into the same directory and have them take priority over the ones in the system, like in windows. Am I missing something that makes Linux unable to do that? (Aside from the obvious bloat of such practices).
Typical Windows programs are stand-alone. If it needs something, like e.g. a DirectX version, it'll come along on the CD. Typical Linux programs rely on lots and lots of other packages (which again rely on others and so on). Since it's free, we get to stand on the shoulders of giants.
If you were distributing it on say a CD, it wouldn't be a problem - simply supply a minimum version of every dependency and dependecy of dependency - all the way down. But if you're providing a download, it would be nearly impossible to distribute 100mb+ of libraries to go with your 1mb program.
So the core problem is to find all the dependencies we already have installed, download those we don't, and point the program to where it can find all these.
Not to mention such fun things as libraries that need to be upgraded as a set - imagine you had DirectX 8 & Service Pack 1, and that DirectX 9 required SP2, SP2 required DirectX 9. The answer? Install both, and it will work. Of course, then Microsoft would combine them to one update.
On Linux, you may have packages from 10 different groups of people. Then you need a package manager to try to figure it all out. And people will not agree on what is the "right" combinations, should it be only rock-stable builds (debian-stable?) or every latest beta build (Fedora-unstable-testing-alpha-something?).
Kjella
Live today, because you never know what tomorrow brings
with a standard package? This way every linux system runs the same installer and can download the same packages. But because every distro does everything just a little different, the installer reads a config file so that everything is dumped into the same place. /usr/src/randomapp
The installer would by default download a binary from one of many sources in a config file. But would have a flag for downloading and installing from source. Also you could specify a file to be installed that is local.
install randomapp -l
or
install randomapp
Uninstalling would be just as easy just type "uninstall randomapp".
Cross platform and compatible on all systems because everything is the same EXCEPT a config file. Makes sense to me.
Instead of trying to standardise packaging, wouldn't it be more realistic to define one standard file where different package managers can fetch information on how a computer is organised? In this way, the authors of different package managers could claim their program is "compliant" with this new standard. Freedom of choice, but still a standard.
10 ?"Hello World" life was simple then
... when visiting Mad Penguin.
...until you can get a major commercial vendor to bite and dump their own package system.
I seem to remember that Digital UNIX was converting to RPM, but it doesn't seem to have panned out.
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
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.
...as railroad tracks. Everyone agrees on how "the wheel" works, and it works bloody fine with the trains you already have even if they all have different track widths. Yet somehow it would be nice if you could grab a train from just anywhere and drop it somewhere else, and it'd fit and it'd work.
That's where we're at today. And every so often, someone tries to suggest a "reengineering" plan to make all the trains operate on the same tracks, without really getting anywhere. Sooner or later one format will succeed, albeit slowly.
Kjella
Live today, because you never know what tomorrow brings
I actually just got one of my bosses to upgrade to Windows 2000 for his development work... his NT directory was called "WINNT35". 'Pain' doesn't even begin to describe it...
See, the legal system is not the way to solve our problems.
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.
It really like what I was saying a few months ago.
I just focused on Debian..
Ploum.net.
It's already been built: Synaptics.
When I decided to try to leave Windows behind (after seeing Knoppix on my laptop, and mainly because of MS's mandatory registration), I went with Redhat. But through freshrpms, I quickly found and latched on to apt for rpm and Synaptics.
Not only is Synaptics just as comfortable to use as Windows' "Add/Remove Programs," but being able to scroll through the descriptions of available packages let me find some great things (like Anjuta, dnsmasq and K3B.) I added Planet CCRMA to my repositories list, and using only Synaptics for installation, I now have a full music studio.
It's not that I never have to edit the occasional text file (like fstab and iptables) to get things working, but I use gedit to do it. And I use the command line only sparingly.
(And I'm now setting up 2 friends, who have only Windows experience, with Linux system.)
Things don't have to be difficult. Use what's out there.
--A long-time lurker
(Perhaps I'll finally register soon)
The way windows gets around this (sometimes) is by placing the old library(dll) in the same directory as the exe calling, while the system retains it's newer version. It's a reduementary form of sandboxing, at least on the file level.
I think what is needed is similar version snadboxing for packages. When installing a new pkg.y that call for and upgrade to lib.x.5, but lib.x.5 causes a cacading dependency problem for the rest of the system, it should give you the option to install lib.x.5 and pkg.y together, without upgrading lib.x.4 that the rest of the system needs. It may need to be recompiled to use the lib.x.5 in a non-standard location, but it would help greatly.
Now, all of this may not work too well if you plan to use pkg.y to talk to pgk.z if they use different version of lib.x, but it's a start. You could allways move pkg.z into the 'sandbox' as well, I guess.
A lot of Linux PC users really are using a "personal" computer, in that only one person generally uses it. This is my situation at work.
At home, though, the PC gets shared by 4 people. So, if I install something new, I'll often want to add it to one of my KDE menus. But then I have to remember to do the same for each of the other 3 users, or go through the pain of walking them through it.
Thus, one feature of my ideal package manager or installer would allow a root install to easily update the KDE/Gnome menus of all users, perhaps being able to choose those in a particular group.
Here's a similar package funded by a dutch institution:
A-A-P
DNA is the ultimate spaghetti code.
On the other hand, binary distributions maintain their own compiled packages. Think about how many different binary packages are available for all your favorite programs across all the different distributions. How much aggregate storage space is being wasted for what is really redundant (yet slightly different) data?
Source-based distributions (Gentoo, FreeBSD) only have to maintain their build scripts. I'm sure that the complete collection of any source-based distros' build scripts is significantly smaller than any binary-based distros' complete collection of binary packages.
Now I'm not arguing for the superiority of source-based distros (they're certainly not for everyone). But the source package should be the standard base upon which each distribution builds its packages. For example, instead of Debian maintaing all those binary packages, why not maintain a method (i.e. a script) for creating those packages?
This would effectively give every binary-distribution a source-based option. My concept is that every distribution would start with a Gentoo- or FreeBSD-like source distribution system, but also maintain a cache of pre-compiled binaries. Gentoo already does this with a few huge packages (e.g. you can download and install a pre-compiled OpenOffice.org package).
In short, I'm suggesting that all the distributions could change their internal infrastructure by adding a source/build script layer, but not affect the actual installation, administration and/or use of the system. Standard disclaimer: I have never worked intimately with any package manager, so much of this is speculation/brainstorming.
This code will find the full path name to the current executable:
// Handle a relative link: // copy up through the last slash: // Skip leading ./: // now put the filename there to get a relative filename: // This may overflow the buffer! // Full path to the current executable is now in buffer
buffer[1024];
strcpy(buffer, "/proc/self/exe");
for (;;) {
char buf2[1024];
int n = readlink(buffer, buf2, 1023);
if (n <= 0) break;
buf2[n] = 0;
if (buf2[0]=='/') {
strcpy(buffer, buf2);
} else {
char* p = buffer;
char* a = p;
const char* b = program_name;
while (*b) if ((*a++ = *b++)=='/') p = a;
b = buf2; while (b[0]=='.' && b[1]=='/') b += 2;
strcpy(p, b);
}
}
(obviously cleaner code that cannot overflow buffers should be written and stuck in a function, but it is not impossible).
...so let's fork it.
I looked at a description of the red Hat RPM file format, and the header seems needlessly complex. It would be better to use a format that is as simple as possible and thus as hard as possible to accidentally screw up.
One possibility that comes to mind is something like the FITS format used in astronomy. You have an ASCII text header followed by binary data. The header is just lines of the form name=value followed by an END statement. This should be flexible enough for any package installation needs -- you can always come up with new parameter names and value sets as needed. Yet it is simple and easy to read. There are no file offsets to worry about.
--- Brian
It's called Red Carpet
It's not the dpkg format or even the apt tools that make Debian so nifty. The thing that makes Debian work is that Debian has put together a formal process for naming, creating dependencies, and testing, so that the packages work together.
The packaging format is just the tip of the iceberg, and people that think that they can solve the many problems with installing software, especially software with complex interdependencies, by slapping some metadata alongside their tarball are simply delusional. apt4rpm wouldn't have helped the RPM based distributions without some sort of centralized repository of RPMs that had been tested together.
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.
What would be really smart would be to copy what Microsoft does with DirectX and enforce strict backwards-compatibility with every version. That way, if you had lib.x.7 you could run programs linked with any previous version. However, I don't know if this is possible with Linux's loader.
Karma: Contrapositive
Personally I believe that the metadata that packages use (dependencies, build, etc) need to be pushed down into autoconf.
./configure && make && make install smarter so that package managers can just read _that_ to build their dependecy trees?
What's so hard about making
Cheers
Stor
"Yeah well there's a lot of stuff that should be, but isn't"
It makes one pine for the days of the a.out format.
-- Stephen.
Checkinstall is a program which helps you in keeping track of programs installed from surce. instead of make install,you run checkinstall which gives you the option to create an rpm or deb or tgz kg(??) Say if you choose rpm ,an rpm will be bult and installed and saved.
Now you can use the native package manager to keep track of the packages you have installed from source.
But this is useful for people who are not afarid to build programs from source.
Neverthless it's one of the best tools for linux.
http://asic-linux.com.mx/~izto/checkinstall/index. php
TechSutra
PGP/GPG == DRM
DRM is where software goes against your will, to protect the rights of others. If I pgp-encrypt a file, you will be unable to access it. However, this is because you have no way to open it without my help. Your own software is not refusing to open the file. Your software is _incapable_ of opening the file. That's the difference. DRM systems, such as those that prevent copying of a music file, could easily allow you to make the copy. They just don't.
* GNOME is written entirely in C, not C++.
* The problems you were experiencing were most likely due to the fact that GNOME 2.x has source incompatibilities with GNOME 1.x.
* There are ways to have both GNOME 1.x and GNOME 2.x installed on the same machine; it's just ridiculously complicated to do so. (Gentoo seems to manage to handle it seamlessly though.)
Every time you run "emerge", a Microsoft drone dies.
The problem is not the different package managers, but that you almost invariably run into dependency hell when trying to install binary packages. This is due to the fact that most distributions install software in a way that makes it difficult to concurrently use different versions of software.
/package/name/version/{bin,lib,...}
If the distribution installed software in a directory structure that included the package and version name, dependent packages could be configured to use different versions of the same packages.
If a new end user tool required a new version of a library, the existing tools that used the old version should not have to change.
Like so:
There would always be points of contentions, of course, like user config-file format changes between versions, but situation would be substantially improved.
I believe I saw a reference to a distribution that worked similar to this.