Hosted by marcoz on 2011-05-24 is flagged as Explicit and is released under a CC-BY-NC-SA license.
Listen in ogg, spx, or mp3 format. | Comments (4)
rpm, rpm5, deb/dpkg, ebuild, compressed files (archlinux), pisi, .tgz (tar.gz file) slackware/vector linux, .tlz (Vector Linux)
Program Distro(s) website notes
conary Foresight Liux/rPath company handles distributed repositories, commit/rollback
entropy Sabayon consists of Equo client (textual), Sulfur client (graphical)
kpackagekit kubuntu uses policykit (any problems if booted computer from a live cd and mounted and chroot'd?)
opkg openmoko lightweight; based on ipkg
pirut fedora it calls yum so it's just a gui wrapper? not sure how widely used...?
pisi pardus (Turkish distro) was based on gentoo. as far as I can tell it now uses its own pkg format
poldek Fedora RPM
portage gentoo ebuilds,
slapt slackware tgz
slapt vectorlinux tlz;
smart UnityLinux RPM5
synaptic ubuntu DEB; graphical frontend to apt
urpmi mandriva RPM
yum redhat/fedora RPM
zypper opensuse RPM
Other useful links:
apt - http://wiki.debian.org/Apt
conary - http://wiki.rpath.com/wiki/Conary
entropy - http://wiki.sabayon.org/index.php?title=En:Entropy
kpackagekit - http://en.wikipedia.org/wiki/KPackageKit, http://www.packagekit.org
opkg - http://code.google.com/p/opkg/
pacman - http://www.archlinux.org/pacman/
pirut - http://fedoraproject.org/wiki/F8_User_Guide_-_Managing_Software_with_Pirut
pisi - http://en.pardus-wiki.org/Making_Pisi_Packages
poldek - http://poldek.pld-linux.org/
portage - http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1
slapt - http://vectorlinux.osuosl.org/docs/vl58/manuals/vl5_slaptget_en.html
smart - http://niemeyer.net/smart
synaptic - http://www.nongnu.org/synaptic/
urpmi - http://wiki.mandriva.com/en/Tools/urpmi
yum - http://yum.baseurl.org/
zypper - http://en.opensuse.org/Portal:Zypper
1) package burn out - will it get to the point where only either large distros or commercial distros have large repos due to the effort involved?
2) I've lost track of the number of times i've heard from people 'our distro doesn't have enough manpower to package ...'
wouldn't it be helpful to not have to use our limited manpower in building redundant packages?
3) in 10 (or less) years when non-technical people take over at Redhat/Ubuntu/other large distro, will they use the package system as a club to beat the other distros with? I'm not sure how, but where money is involved, you can feel assured it _will_ happen.
4) current state of packaging systems in linux is like sound systems were 10 yrs ago.
remember esd vs arts vs vs ...? each desktop environment had its own system. sound in linux was painful and a complete joke. it still has a ways to go but it's _SO_ much better now that it was. does anyone want to go back to that?
pulseaudio isn't perfect but it's so much better than what we had before. and it's ONE system!
can you image if printing and authentication were like the packaging systems? image if everyone had their own printing system instead of CUPs? imagine if there was no pam.d?
5) I believe packaging systems are NOT about choice. the exact opposite. it's about vendor lockin and NIH.
(we'll do it OUR way because we can do it better or the 'proper' way. "so-and-so does blah, which is
choice is being able to write a script in php,perl,python,bash,csh,... on the SAME system.
because I can CHOOSE. If I have a debian box I can't choose to use RPM or ebuilds, same for those other systems.
of the systems I've used: deb, rpm, rpm5, portage, (and tarballs if you count linuxfromscratch)
and the managers I've used: yum, urpmi, smart, kpackagekit, synaptic, apt-get, emerge
each system has little features the others don't. but there is nothing that one system has that couldn't be added to the others.
Subscribe to the comments RSS feed.
Comment #1 posted on 2011-05-25T18:43:38Z by Cillian de Róiste
You missed one! :D
Nice podcast! I do agree and (although you alluded to it) I think you didn't explicitly mention how really *every application* and programming language also has it's very own package manager (Firefox, LibreOffice, Perl, Ruby etc.).
I've run a fair variety of distros in my time too and this is a problem that also bugged me. That, and the fact that packaging systems often make life difficult. You may need to wait months for the next release until you can install the latest version of an application, or be forced to run an entirely unstable version of your distro even though you only care about one of two applications. Also, if something goes wrong, you can't easily jump back to a working system.
While I agree that there are already too many packaging systems out there which do roughly the same thing I've found a system which truly fixes a lot of problems for me and it uses a very different and radical package manager. Amazingly, you didn't mention it in your comprehensive listing, but it's not surprising really. I think people are feeling the same fatigue you present and just aren't interested in yet another system.
Comment #2 posted on 2011-05-27T07:03:24Z by Kyashii
This is kind of the "fashionable" thing to complain about today. Much like people believing that everyone runs either Gnome, (Unity,) KDE, XFCE or LXDE and that no other desktops matter.
First of all I would say that GUI frontends aren't really a part of the package manager, hence I think those don't really matter in this discussion, and I think it is a bit unfair to count those alongside package managers.
The problem with saying that there are too many package managers is that it is like saying there are too many Linux distros.
Because of file system layout differences, differences in init scripts, differences in how current the distros want to stay, differences in if the want to do source or binary packages, differences in if they think it is the role of the package manager to handle dependencies, differences in if they want to do rolling release or separate release versions... and so on every distro would still need to have it's own set of repositories which would negate a lot of the benefits of having a single package manager since packages would still not be cross-compatible.
This means that as long as there is distro choice it seems impossible to ever make packages fully cross-compatible to the point where a user could install a package on any distro. A lot of packages would work if you put in a lot of user-interaction for where things are on your computer and you do packaging like sta.li where everything is statically linked so there are no dependencies... but it wouldn't work anyway if the package relies on a certain version of the kernel, X11 or a driver etc as statically linking those wouldn't really make sense.
Since there is no one way to structure a Linux filesystem, a Linux init system or a Linux release schedule you will never really fix that issue if you do not want to cut Linux down to one single distro.
Comment #3 posted on 2011-05-30T22:19:35Z by Cillian de Róiste
My comment seems to have been chopped off. I mentioned NixOS which has a very radical approach to package and configuration management and (Nix) can comfortably co-exist on systems which use other package managers.
Comment #4 posted on 2011-05-31T03:02:29Z by marcoz
at least one...
I think I missed a bunch. :)
Only so many hours in the day.
You're right, I didn't talk about firefox, perl, python, ... having their own way of installing stuff. I rambled enough as it is, I'd hate to imagine how much more I would have had I brought those up. yaourt (pacman alternative for arch linux) has that ability and ebuild also can do that with perl. It'd be really cool if that was a more standard thing. Thanks for listening and the comment!
There's nothing fashionable about it from my perspective. I've heard almost noone complain of package system proliferation, in any of the forums, chatrooms, mailing lists or news aggretators that I visit regularly. In fact, I hear exactly the opposite on a fairly regular basis. Someone excited about their project, a new package manager that either fixes a certain problem in another one or a fun project they have been 'kicking around and have been working on for the last 6 months' Possibly we hang out in different areas though.
I don't see packaging as similar to the 'everyone runs GNOME, KDE, .... argument. Those are about choice. Please refer to my comments about 'things able to run on the same system'
I don't believe the file system heirarchy or dynamic vs static libs or system init scripts as unscalable walls. Are there differences to be figured out? Of course, but a file that lies on libcups.so.1.2 or libcups.a relies on that library regardless of where it lives. (use /etc/ld.so.conf) THings like how the daemon gets started, obviously depends on the particular system, but to say that things like this make it impossible to have one packaging system but still allow multiple distros is something that I don't believe. Thanks for listening and commenting.