Two Package Manager
|
| Author | Content |
|---|---|
| Jeff91 Oct 12, 2011 9:10 AM EDT |
I've always wanted to like Sabayon. It does a good thing in theory. The stopping point for me is that they are shipping a distribution with two package managers that when used interchangeably cause the system to come to an unusable state. ~Jeff |
| Grishnakh Oct 12, 2011 12:30 PM EDT |
It sure would be nice if the different Linux distros could settle on a single package manager. I can understand why people don't want to settle on, for instance, a single desktop environment (after all, look how many people hate Gnome3 and Unity, with good cause), but what could possibly be so different between dpkg and rpm that justifies keeping both around, causing distros to be completely incompatible with each other? This is a place where fragmentation needs to be avoided. |
| JaseP Oct 12, 2011 12:32 PM EDT |
I like choice, personally... |
| Grishnakh Oct 12, 2011 12:37 PM EDT |
JaseP wrote:I like choice, personally... I like it too, for things like text editors and desktop environments. That's because I can say precisely what I don't like about certain editors or DEs, and why I like other ones better. Can you say precisely what's so great about rpm or dpkg that the other one doesn't have? And which justifies creating incompatibility between distros through their use? This isn't like text editors; it doesn't matter which text editor you use to edit a file, as the end result is the same. It generally doesn't matter which web browser you use, as long as it renders properly according to standards. Having a different text editor available in your distro isn't going to automatically make it incompatible with software packaged for another distro, and force software makers to create different versions of their software for every distro. But having different package managers does exactly that. |
| phsolide Oct 12, 2011 4:04 PM EDT |
A reason must exist for proliferation of package managers, just like a reason must exist for the proliferation of PHP templating frameworks, or C++ string objects. Form follows failure, after all. One might guess that package management is either still in its infancy, or its one of those problems without a general solution, like finding the roots of a Diophantine Equation. |
| Grishnakh Oct 12, 2011 4:39 PM EDT |
phsolide wrote:A reason must exist for proliferation of package managers I think that's a bit of an exaggeration. There's only two package managers, dpkg (used by the Debian distros) and rpm (used by Fedora, Suse, and Mandriva). There are a few minor players, namely Gentoo which has their own system for automatically downloading and building from source, and of course Slackware which doesn't use a package manager at all, just .tgz. The overwhelming majority of distros are centered around either dpkg or rpm. As for being in its infancy, this situation has been around since the late 90s when all these distros came into being. 15 years is an eternity in the computer world. This isn't a situation with a good reason, it's caused by NIH and inertia. Red Hat invented rpm, so they refuse to switch to something else. Debian invented dpkg, so they refuse to switch. Distros which derived from those use the same package manager. The Linux community and ecosystem would be much better off if the two sides got together and created a single package manager and used it. Of course, there's always going to be the oddball distros that don't join in, like Slackware and Gentoo, but that's OK, you don't need everyone doing the same thing, just most people, for a standard to be effective. |
| jdixon Oct 12, 2011 4:50 PM EDT |
> ...and of course Slackware which doesn't use a package manager at all, Slackware has a package manager, pkgtool. It just doesn't handle dependency checking. |
| mbaehrlxer Oct 13, 2011 12:09 AM EDT |
there are a bunch of package-managers out there. not enough to call it proliferation yet though. the reason packagemanagers are replaced (and thus the number of packagemanagers is only growing) is probably similar to computer languages.
once you use one package manager it is a major effort to switch to another. in difference to computer languages, you can only use one package manager at a time. you can use several languages at the same time on the same machine. so proliferation of packagemanagers is much harder to achive. you don't just write a new one on a whim. let's just say that's a good thing, and be happy that there are not to many of them. the downside however is that it is really hard to innovate on this area. because even if you come up with a much better packagemanager, it takes a lot of effort to make distributions adopt it (and that's probably an understatement). so as a result we are stuck with deb and rpm. they are not the best packagemanagers we have. they are still here because of how hard it is to switch. greetings, eMBee. |
| Fettoosh Oct 13, 2011 12:18 AM EDT |
Quoting:so as a result we are stuck with deb and rpm. they are not the best packagemanagers we have. If deb & rpm aren't the best, which ones are best in your view? |
| BernardSwiss Oct 13, 2011 7:15 PM EDT |
I would like to second that question. [ Hint for those qualified to express an opinion ] : Something on those lines would make an excellent article. |
| TForsman Oct 14, 2011 4:34 PM EDT |
Here is some info about Conary, that Foresight Linux uses. And is also in Openfiler (server). At anytime an update fails Conary will rollback to the previous job leaving your system dep complete and fully functional. How Conary Organizes Packages If you use debian or rpm repositories…you know that inside a repository directory “stable” (as an example) are all the stable packages for your distribution. The packages are versioned according to their upstream version (if the repository maintainers are sane) and maybe arch and revision number. This is done by hand. It is managed by hand. If developers/packagers cross names between repositories you are brought into dependency problems. To illustrate this concept, if you and I both packaged firefox3 and named it accordingly…and someone used both your and my repository…our versions would conflict because the packaging system wouldn’t know which one to install. Conary takes the manual operation from this…if you use a Conary based system, yourrepositories ARE VERSIONED. In other words, the repositories aren’t static directories that contain a bunch of packages…they are versioned branches that contain components of software. These components (packages) are also versioned according to upstream version…but revision is handled automatically by Conary…no manual process. This eliminates the possibility of having two packages named the same exact thing in different repositories. In other words, if Joe Schmoe is packaging Liferea for his apt.joeschmoe.com repository and names his package the same thing as say Joe Smith’s package for Liferea in his apt.joesmith.com repository we run into problems. With conary this NEVER WILL HAPPEN…EVER. This kills about 90% of dependency problems all together. But what about arch? Arch is architecture…32bit or 64bit…PPC and more. Once again, you’re bit by the possibility of conflicting names across repositories. You’re also limited in the name because a developer has to put the architecture INSIDE THE NAME. Take a look at liferea as an example: liferea-1.2.2-2.el5.rf.x86_64.rpm. Is this easy for an end user to understand? Is it the same as liferea-1.2.2-2.el5.rf.x86-64.rpm? Conary takes a different approach. Each package has a ‘flavor’ that it is ‘cooked’ (committed) in. There may be a 64bit flavor, 32bit flavor, Xen flavor, and so on. This flavor is visible to the user only if the user requests to see it…and it is NOT inside the name of the package. The package is still called, simply enough, liferea. Revision number, arch, upstream version, etc…are all handled automatically by Conary. You can see how creating and maintaining software would rely less on a manual process and more on automatic source controlled one with Conary. You can also see how organized Conary is with its packages. (this chapter comes from devnet) Conary treats packages as change-sets and not as a bundle of files. This means that when updating a package, Conary communicates with the repositories to determine what needs to change on the system to install the new package and only downloads the bits needed for that change. There are many advantages to this approach, but most visible to the user is the efficiency in bandwidth and speed. When updating a large package for the first time, you will essentially download the full package, however, when updating in the future the downloads could be significantly smaller. Here is an example: installing Abiword 2.2.6 on a system for the first time would be approximately a 15MB download, however updating to Abiword 2.2.7 is only 2.4MB. How can I be sure things still work if I remove a component from my system? First, Conary warns you if you are about to remove a component that is used to resolve a dependency elsewhere on the system. Conary keeps track of these dependencies for you. Second, you can use the –deps option to display dependency-related information. Furthermore, you can also use –file-deps to list component dependencies at the file level. Results display what the trove “requires” to resolve its own dependencies and “provides” to resolve other packages’ dependencies. You don’t have to track this information unless you really want to do so; trusting Conary’s warnings is usually enough to prevent mistakes when installing and removing software. What’s that colon for? Is “chromium:runtime” different than the “chromium” package? It is different, but part of the same package. When the package name is followed by a colon and another name, such as “chromium:runtime” and “chromium: doc,” this references a component. When the package is first built, Conary separates out the files into components. Each component represents some logical grouping of files within the package, such as everything needed to run the software or the documentation for how to use the software. This gives the flexibility for other packages to resolve dependencies by bringing in components rather than entire packages. It also gives users the freedom to uninstall components that are just taking up space without removing an entire package. But, enough about how awesome Conary can be. So unlike other packaging systems, where you might have 2 packages, firefox and firefox-devel, Conary would have one package with the devel headers split into firefox: devel. This is a great thing, you no longer end up installing -devel packages from random repos in your sources.list just because it looks like a newer version. The devel headers are just part of the same package, you just don’t have to have them installed. These components combined with rich dependancy information really shines. Well, that's just a brief info about conary. Today, it also saves all installed packages in a file, so you can easily remove that name in that file and that package + dependencies thats not in use, will be deleted too. Something called system-model.......... A new update mechanism called “system model” is added. In this model, a file called /etc/conary/system-model describes what should be installed on the system. This file is modified by certain conary update commands, and can also be edited with a text editor. The system model allows a system to be updated relative to a search path that includes groups as well as labels, leading to more coherent sets of updated packages. It also allows re-starting updates with transient failures; the filename /etc/conary/system-model.next is reserved for storing the system target state during an update operation. The system model mode is intended to become the normal update mode for Conary-based systems in the future. It works by creating a set of troves that define the system, and then moving the system to that definition. It is conceptually similar to building a group into a repository and then migrating to that group. Significant differences include: In a group, all trove references are absolute, but in a model,you can choose whether references are absolute. Migrating to a specific version of a group will always move the system to the exact set of packages referenced, but re-applying a system model will update troves that are not pinned down to a specific version. There is no group name for the set of troves. There is no version for the set of troves. (The version operation in a system model does not provide conary versioning.) Path and version conflicts are not checked when assembling the set of troves. (No group policy is run at all.) This means that path and version conflicts will be found only while installing the packages. A system model that installs only a single group will function similar to migrate mode. The most obvious difference is that migrate mode honors variations in byDefault settings in the system database(that is, an optional component of the trove(s) migrated to that has been installed on the system will still be installed after the migrate operation finishes), whereas a system model update honors those changes only if they are represented in the model itself. // TForsman |
| Grishnakh Oct 14, 2011 6:51 PM EDT |
@TForsman: Sounds great! Now we just need to get all the mainstream distros to switch to this. |
| mbaehrlxer Oct 15, 2011 12:48 AM EDT |
i'd just like to add that tforsman is an active developer of foresight linux. (i am a not so active one :-) i switched to foresight in 2007 after looking at it for a year very reluctantly. what possibly could it do better than debian (and ubuntu which i was testing at the time too)? the desktop is nothing extraordinary, just plain gnome. (although given the modifications some distros make that might be extraordinary in itself. foresight prides itself with shipping packages as close to upstream as possible.) conary was the thing that convinced me to stay. conary was written by former redhat developers who used to work on rpm. they analyzed the state of packagemanagers and built conary based on those learnings. from the things that tforsman mentions i'd like to elaborate on what a group is. on debian or rpm based systems, when you do upgrade, then the packagemanager will pick the latest version from all packages. that is, if you upgraded yesterday, and i upgrade today then our systems may be different because i might have picked up a newer version of some package. in conary, all packages that are available for install are assembled into a group. this group is created by the distribution developer. when the group is built, it stores the version of each package. as a user packages are then installed from this group. just like packages, the groups have versions. when a package is updated, the group needs to be rebuilt (with a simple command) and when i update my desktop then the package manager first checks for a new version of the group, and then finds out which packages are updated within the group. to go back to the example, if you upgraded yesterday, and i upgrade today but i want a system identical to yours, i can ask you for the group version that you have and select that version explicitly. you can imagine how that simplifies testing. if a user has a problem, usually all we need to know is the version of the group. that alone will tell us every version of every single package that you have installed. or consider corporate deployment. the best practice for rpm and deb, as hinted in the article above, is to create a company internal repository where you can control exactly what versions are available, and then synchronize machines. with conary, all i need is the group version, or, as tforsman points out, the new system-model file. this ability is so significant that rpath, the company which develops conary even offers rhel and centos (and ubuntu server) repackaged in conary. (and apparently conary is now available for windows too) if you want to create a custom system for many machines, you can create your own group, inherit an existing group and make the necesary changes to it. a group can contain packages from multiple repositories,so there is no problem to mix and mach and still have full control over what is going on. this reduces the effort needed to create a derivative distribution by a huge amount. groups also help with automated rebuilds of the source. if a library is updated, then all packages that depend on that library can be rebuilt automatically with a single command. recipes for packages are astonishingly short. in most cases it only takes specifying of an url and some dependencies in order to build a package. conary also remembers if i remove packages, even files, so when a group or a package is updated, then such removed files are not reinstalled. since switching to foresight in 2007 i have never reinstalled a system once. at one time in my early foresight days i did manage to botch a system so that i couldn't figure out how to fix it. i didn't need to reinstall though, all i needed was to ''migrate'' to a default group which caused conary to remove any packages that i had installed from hand and add any packages that i had deleted.the result was a running system that looked like it had been reinstalled, but with the configuration and all the stuff that is not managed by conary still in place. conary is addictive: http://wiki.foresightlinux.org/wiki/display/DEV/WARNING greetings, eMBee. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!