Slashdot Mirror

Fix your package manager!

Assuming you mean rpm vs dpkg, this is irrelevant. rpm has very few problems to fix.

I am sick of downloading packages from weird websites

If you're running RedHat, you shouldn't really be doing this anyway, you should be using up2date.

If you need packages not supplied by RedHat, there are repos for RedHat.

But, this has nothing to do with "fixing the package manager", it is more about the available packages on RedHat. However, a lot of the packages *I* need that are missing on RedHat (we have approx 150 source packages in our internal repo which we build for RHEL2, 3 and 4) aren't packaged in Ubuntu. And, some of the ones I need which *are* available on RedHat, aren't available on Ubuntu either.

YUM seems tacked on, and I've never gotten it to work properly.

While yum isn't IMHO the best rpm tool equivalent of apt, I've never seen it not work.

Now, you've been comparing apt to rpm, but there are many other aspects to package management that RedHat does get right, for example the features of up2date/RHN:

-grouping of servers and scheduling of updates (that you can show your CTO, not some script)
-profiles in RHN for kickstarting servers
-config file channels (something like cfengine, but built into RHN)
-ability to kickstart servers from the RHN interface

With an RHN satellite server, you can have custom channels, which you can then use for both of the above, but doing all package management from the satellite server.

So, don't compare rpm to apt (which is a mistake in itself) because RedHat ships/supports fewer packages, and then leave out all the features RedHat *does* have regarding package management.

Also, last I checked Ubuntu's kickstart was still missing lots of features I actually use (even though we don't use Satellite, we use kickstart and our own repos, which we use to install packages during the %post section of kickstart using smart.

So, I can see why RH isn't worried about Ubuntu.

And that's why I'm looking forward to being able to do smart --install package in the not too distant future. Sure, some distros use RPM and yum databases, some use RPM and apt-rpm, some use DEB and apt databases, and then there's tgz formats... except smart, as a dependency resolver and installation system has pluggable backends. Not only is its dependency resolution system better than apt or yum, it can run against yum-rpm, or apt-rpm, or apt-deb, or even slackware tgz databases, so while different distros can use different packaging and repository systems, the user can have the same installation frontend regardless of what distro she uses.

Of course some distros will still want to go their own way (I'm sure Gentoo will continue to be what it is), but I think it is reasonable to hope and ask the major distros to, regardless of how they want to package and store, make smart available as the client to install software. Hopefully that will be the result in the not too distant future. It helps if more people know about and advocate smart of course...

Jedidiah.

The Smart Package Manager project has the ambitious objective of creating smart and portable algorithms for solving adequately the problem of managing software upgrading and installation. This tool works in all major distributions, and will bring notable advantages over native tools currently in use (APT, APT-RPM, YUM, URPMI, etc).

What I'd like to see is a GUI based package manager that could just bloody well figure out that your repos are .deb based or .rpm based, and act accordingly.

You might be lookign for Smart which is a potential replacement for apt. It does the dependency resolution and installation that apt does but with more advanced dependency resolving algorithms (seee their README for examples). It has command line and GUI modes of operation so there's no need for another program to provide a GUI front-end like Synaptic does for apt. Best of all it has a system of pluggable backends, which means it (right now) understands apt-deb repositories, apt-rpm repositories, yum repositories, and slackware package respositories among other things, and is thus a common frontend that could be used for (almost) all distributions. You can even mix and match repositories if you like and have it pointed to, say, an apt-deb repsoitory and a yum repository and it will do dependency resolution against both. Of ourse mixing up repositories (from potentially different distributions) has its own natural compliations and probably isn't advised, but that's as much to do with naming, packaging and LSB stuff as anything.

Jedidiah.

First of all migration is raised as an issue: "When Regular People fire up the Linux desktop for the first time, the browser, office suite, email client, IM client, file manager, etc, each need to carry over as much as possible of the Windows application settings and all or very nearly all of the user data."

First of all that's a steep ask, but secondly I just don't think it's necessary. If that was required for people to switch no one would ever move to Apple. It's definitely a nice idea, and in the "nice to have" category, but I don't see that it's a deal-breaker.

The second point is API stability: "A user should be able to install Fedora Core 4 and go grab the latest Firefox release from Download.com and have it work without the need for finding and installing compat-libstdc++ or whatever."

This one is fixed - if developers would actually pay attention. Autopackage allows developers to package up their application into a self installing executable that can do dependency resolution. At that point not having compat-libstdc++ is the developer/packager's fault: they ought to have included an Autopackage for it in their repository so the installer can fetch it if it finds the right version of compat-libstdc++ isn't already installed. Better still, the people at Autopackage provide relaytool which allows developers to smoothly fallback to other library versions: for example, you can have your binary use the new GTK+ file chooser if it is available, but fallback to using the old one if it isn't. Which is really saying that the problem has been solved, it's up to the developers and people releasing the software to make use of the tools available.

The third point is preferences: "Gedit has about 30 user preferences spread across 5 tabs in a preferences window -- Notepad has about three."

Now that's not a great example becaue Gedit does a hell of a lot more than notepad, but I think the point is still very valid. To be fair I think GNOME has been putting in a lot of work on this front, and trying to clean a lot of these things up. That work is ongoing, and we can expect to see continuing improvment. That is, the way forward has been laid out, it's just a matter of continuing down the path.

The final point is "comfort":"The final major issue is comfort. Linux must feel comfortable to Windows users. Most people using computers today have been at it for a while now and they've been at it on Windows. Don't mess with their basic understanding of how things work."

I have to say, I think this one is a little dubious. If there is a better way of doing things why not do it? I think constraining yourself to the way Windows does things is a little pointless. There are plenty of things Windows does well, and it's fine to follow those examples, but there are plenty of things Windows does badly, and slavishly copying broken behaviour really doesn't make much sense.

I think the real point here is: be patient. I think the points are valid, but they are also largely well known, and being dealt with. Linux on the desktop is not going to "take off" anytime soon, but the rate of improvment in desktop Linux is tremendous, and it is making slow but steady inraods. Software installation (which has been the recent bugbear that people complain about) is looking quite good with Autopackage and Smart, but both of those are very new and it's going to take some time before a lot of stuff shifts over - that's life. GNOME is working hard on the preferences trim down and clean up, and, I think, is workign towards a fairly clean easy to use Desktop. KDE is headed in a different, but equally valid and interesting direction - I think the divergence is going to end up providing some real significant choice. Finally I think once all these bits properly fall into place and desktop Linux manages to make a dent in the enterprise (which seems to be where the major distros

I'm guessing that if they're doing this they'll be doing it via smart, a very nice looking potential successor to apt. Basically it does the dependency resolution/download/install that apt does (with more powerful dependency resolution algorithms and a built in GUI) but does so via a pluggable backned system which means it can access apt-deb resositories or yum repositories or apt-rpm repositories, and even slackware packages.

My reason for guessing smart is the answer is that its a Conectiva initiative, which is to say Mandriva. If Mandriva wanted to use apt-deb repositories this would probably be the easiest way for them.

Jedidiah.

Smart Package Manager makes installing, updating, and removing software easy. It subsumes deb, rpm, apt, apt-rpm, yum, etc, and even lets you use multiple application repositories even if they are in different formats (apt-rpm, deb, yum, etc). Really, installing software can be as easy as searching for what you want in Smart's GUI and then selecting what you want to install. Removing an application is similarly easy, and updating is even easier!

Smart also has a commandline _and_ GUI interface, so you can use whatever interface you like best, unlike yum. It also allows for prioritizing package repositories so that you can make use of any repository you want and leave overlaps/conflict resolution up to smart.

I am using it under Fedora Core 4. It is still beta, so it has a few cosmetic bugs, but otherwise it works nicely. If you are using Fedora Core 4 and want to try it out, you can, even if you are already using yum or apt, as Smart can be used alongside other managers.

rpm -Uvh http://apt.sw.be/dries/fedora/fc4/i386/dries/RPMS/ smart-0.35-2.2.fc4.rf.i386.rpm
rpm -Uvh http://apt.sw.be/dries/fedora/fc4/i386/dries/RPMS/ smart-gui-0.35-2.2.fc4.rf.i386.rpm

1. The packaging system is user-unfriendly.

It's actually pretty good at what it is - a means to package a diverse system that can be tailored to the user. Things like Smart (a Conectiva/Mandriva project even) and Autopackage help a lot. To get the packaging systems you want you need to fix #4, and I don't think that's likely to happen (at least not successfully).

2. The locations of programs are user-unfriendly.

Really? Any program that actually supports the freedesktop.org desktop entry file is readily accessible to the user unless they use some WM or DE that doesn't bother to use them - which means they've gone out of their way to complicate their lives. As for where the programs are stored on disk ... well, that doesn't really matter does it? You want a searchable tag/label based system, so why not consider the package database as such a label view - you can see all the programs on your system with ease through the "package label" view of your filesystem, does the physical location really matter that much to you?

3. The folder layout of Linux systems is user-unfriendly.

To some extent I agree, but we're dealing with legacy here... even OS X and windows have some odd folder locations and names carried over. Besides, there's always GoboLinux, which I presume you already know about.

4. The lack of a standard base of installed libraries is application (and thus user) unfriendly.

This is the big one really. If you want a fixed mandated core set of libraries that the user is forced to install... well, grab yourself a nice mandated controlled system like OS X, because Linux probably isn't what you're looking for. In theory you could just set up a distribution that has such a guaranteed base set of libraries, and in a sense some already exist - try Linspire, or Xandros. The catch is that people write applications for "Linux" not "Debian, stable" or "Linspire 3.1" or whatever. Given a random open source application it will make whatever assumptions about libraries it cares to - it's up to the packages to make sure those dependencies are met. FOSS applications tend to be coded against "whatever system the developer cared to use" rather than specific distributions and versions. Commercial developers maybe? Well they do have requirements - Oracle requires particular versions of Redhat in standard installs. Other commercial developers can do that if they like. Alternatively they could accept that the Linux world is a diverse world and restricting yourself to the one distribution that is guaranteed to have everything you want where you want it is a little limiting. You can always use Autopackage and handle the dependency issue elegantly in a way that's effectively invisible to the user.

The fact is that different distributions are different. You seem to be asking for all (or most) of the distributions to agree on a firm fixed set of base libraries. Distributions are different competing companies often however - you may as well ask Apple and Microsoft to hammer out a combined base set of libraries that you can be guaranteed to get in both OS X and Windows. Maybe that's a good idea. Maybe CoreImage on Windows and DirectX on OS X is what you'd like to see. I'm not so sure it will happen though.

Jedidiah.

True. I was running out of time, so I ended up shortening it to "the OS must promise a specific set of APIs". What I was trying to get at, is that nearly all APIs that are useful to multiple programs that you may have installed (i.e. I probably won't have two Word processors, so sharing Word processor specific APIs is pointless) tend to be provided by the OS vendor. Apple handles this via the use of "frameworks", a package similar to APPs. The catch is that only Apple tends to distribute these frameworks. As a result, Apple has made themselves the only source for system wide APIs.

And that's a very lovely idea and will make for very easy packag installation. It is not something you'll ever get on FOSS Linux however. The FOSS software community improves it software in an evolutionary sort of way - you get a whole lot of different versions of basic libraries and tools, and eventually you get some consensus on them. The key is that the whole system can be overturned - perhaps E17 will turn out to be truly amazing and a shift will occur, perhaps Y-Windows will get completed and turn out to be well worth pursuing... the point is that these decisions are made not by corporate management, but simply by what manages to get the most hackers interested in and coding for/with it.

What I'm really trying to say is that FOSS is utterly chaotic, but draws strength from those chaotic qualities. What you're talking about is eliminating some of that chaos - and I think there's certainly merit in that idea, I just don't think it will mix well with FOSS. If you want a organised mandated structured set of required libraries and APIs use Apple (or start your own OS). If you want the masses of software and vitality of the FOSS world, you have to accept a certain amount of chaos in return. What we need is better mays of managing that chaos: I don't think we can eliminate it.

Even singular repositories screw up. A few years ago when I tried Debian, I ran into dependency hell out of the main repository. That wasn't supposed to happen. I've even had it happen in my favorite repository, the FreeBSD ports tree.

But things are getting better. Check out Smart a new dependency resolver with far better algorithms than apt (along with more flexibility at the backend package level). As I said, I don't think you can eliminate the chaos, but you can do a lot better job of dealing with it.

Repositories are useless for commercial software. I understand that OSS developers think everything should be free as in Airplane Peanuts, and free as free to go to a Hawaian Backyard Party, but there are still plenty of examples of commercial software that can't go in these repositories.

And that's where things like Autopackage come in. As long as your base libraries are managed by something like Smart, then Autopackage is fine for those 3rd party extras - it will use the libraries if you have them, but it can grab whatever else it needs if you don't.

Don't fight FOSS's strengths, instead figure out how best to cope with the weaknesses that are the flipside of the strengths.

Jedidiah.

No. The problem is that it BREAKS the package management of those systems.

So now I'd have to use TWO methods of updating my system. Great. Just what I was looking for.

Autpackage should sit peacefully alongside other package management systems, it is designed to be complementary, nt a replacement. As to a central place to manage your packages from, try Smart - it gives you a single interface view to your packages whether they be via RPM, DEB, TGZ or whatever. I have been contemplating writing an Autopackage channel/backend for Smart so that autopackage packages that have been installed will show up in smat and can be removed etc. from there as well.

Jedidiah.

--
Simon

Sure, there's an issue of non-standard toolkits, etc, but the first obstacle to standardizing anything is the install. Autopackage provides the possibility of a single way to install AND uninstall applications on every Linux distribution. That's why it's important.

I think Autopackage is fantastic, and am looking forward to the day when most developers package their software that way. If you're looking for a standardised way to install and manage software though, I'd suggest you look into Smart as well.

It's complementary to Autopackage - Smart covers respositories and distribution provided packages (As nice as Autopackage is, it isn't designed for install/upgrade of the base system). Smart is effectively a replacement for apt/yum/urpmi etc. It is a package manager and dependency solver. The important point to you is that unlike all those tools mentioned it is completely pluggable for backends and channels. That means it can (and does) support .rpm, .deb, and even slackware .tgz. Moreover it can understand apt repositories, urpmi repositories, yum repositories, red-carpet channels etc. It can even mix and match between those if you like (though messes may result from randomly mixing distro repositories).

The point is that, in theory, every current major distro (presumably even gentoo, I haven't looked at the details, but I imagine an ebuild backend can be written as well) can use Smart as the base software install/patch/upgrade interface, regardless of what they do behind the scenes. That means (presuming it gets the uptake it deserves) we could see a (from the user point of view) single way to install/patch/upgrade base software on every linux distribution - the fine points of package format, repository layout etc. can be hidden behind Smart's common interface.

Combine that with Autopackage's interface for third party/additional applications, and managing software on Linux will look more clean, consistent, and uniform than anythign else.

Jedidiah.

So you love Apt or yum. Great. Apt does not mean .deb. Apt can still do its normal great things using rpm formatted packages, so clearly the greatness comes from the tool, not the package specification.

The fuure of package maangers, like Smart, make this even clearer. Smart is like apt (but has better dep resolution algorithms) except it supports pluggable backends - that means currently Smart supports .deb, .rpm, and even slackware .tgz. It can manage those from apt repositories, yum repositories, urpmi repositories, re-carpet channels, whatever. You can even do a mix and match between formats and repository types if you want (though that, of course, can get messy).

The point is that package management and dependency solving are largely independent of package formats (as long as the format contains some dependency information). We can have a global package manager that works everywhere and doesn't care which package format it happens to be working with.

Jedidiah.

So basically even though the RPM based distros were already using APT for RPM for years, Fedora decides to ditch it in favor of an inferior package manager Yum, and then they continue to update and improve Yum until it actually has some advantage (though tons of disadvantages still) over APT for RPM.

Come now, everyone knows Smart is the future of package management. Yum is clearly just filling in time until Smart becomes the standard (even on Debian).

Jedidiah.

Good change it will be neither. Odds point toward smart.

Conectiva made apt-rpm. They also made the smart package manager, which I think is underrated. I hope the Mandrake guys see its potential.

Conectiva Linux will not exactly shift to urpmi, but instead it will be merged into Mandrake Linux.

And remember guys, we're called Conectiva, with a single "n".

However the author of apt-rpm is working on a new package manager, smart, which looks very promising, but which is still alpha.