Slashdot Mirror

I've been using smart package manager nearly exclusively for a long time now. There is the occasional unfortunate GUI bug but they seem to get rectified pretty well. And if you want, you can always use the CLI backend.

http://labix.org/smart

I see that post has received some positive moderations so I guess people might be interested in more info, which can be had here : http://labix.org/smart

I first started using it because apt or rpm (apt, I think) didn't handle dual architectures. I run on x86_64 and it's sometimes useful to have packages installed for x386 too - Android, for example. The smart package manager has no trouble with multiple architectures. Actually, I think it was a little while ago now and IINM, apt does now handle multi-arch ok.

Anyway, FWIW, I've been very happy using smart.

give smart package manager a try :

http://labix.org/smart

I used in on FC6 and Ubuntu (though it's been a while since I last used Ubuntu).

check out smart. on my openSUSE 10.2 system, it does just what you said: you can add some random repo from the internet, and smart handles dependency calculations and updates.

#9. Good point. Being able to easily roll-back an "upgrade" that didn't work would be a very nice feature. So I've marked this as number nine.

In fact, Ubuntu might be switching to the Smart Package Manager http://labix.org/smart/faq which seems to support this functionality.

I also left out ...

#10. Mark packages so that they will NOT be upgraded. The same as I can do with apt.

installs new software correctly, in default and custom locations

uninstalls old software correctly

updates old to new software correctly

is aware of and can work with custom-installed libraries and dependencies (i.e. EVERYTHING doesn't have to be installed using this system, some stuff can be compiled from source or downloaded from third party).

is scriptable through some command-line interface

isn't a pain in the neck

As far as I know, none of the software installation systems out there for any platform meet all of the above requirements.

I am not a Linux user, but I am a software developer, and it seems to me, that ALL the distros could benefit from a universal package manager, that was compatible with all the major package types?

This actually already exists and works quite well I might add:

http://labix.org/smart
http://www.eweek.com/article2/0,1895,1776186,00.as p

Perhaps I should have said "the RPM experience" instead of just RPM. I realize it's just a package, like .deb, but that doesn't change how hard it used to be to work with them, even with websites dedicated to hosting every dependancy you could find. I was just curious to know how the overall experience has improved.

In Fedora at least things are much better than they used to be. A lot of the user maintained packages which used to be spread over lots of repositories are now mostly collected in Fedora Extras, which has a proper review process to make sure that it's consistent both with Core and the rest of itself.

There are still other 3rd party repositories containing either packages which redhat can't host for legal reasons (patents, licenses etc), or packages which haven't gone into extras for some other reason. Some of these make efforts to stay compatible with core/extras, but you still occasionally get version conflicts when using multiple 3rd party repositories. In these cases there is now the Smart Package Manager which does a much better job than yum of figuring out the best way to resolve these conflicts.

Things have improved a lot since the RH7.x days.

With modern packaging systems, there's occasionally a dependency that is just automatically marked and installed, but mostly it just becomes impossible to install something -- and I fear to install from source as in option 2 above, for I may break the packaging system. A package depends on packages X, Y, and Z, each of which have ten dependencies, and most of which conflict with others, or are reported as "won't be installed" but no reason is given. If I find a way to force it, it doesn't work, or it breaks other packages, or most likely it breaks the packaging system.

If you are running a distro (say Fedora Core 6) against potentially inconsistent repositories (say ATRPMs), then you need a package manager that is smarter than APT or YUM. I've used Smart Package Manager to solve these complex problems for a while. It's not perfect - it may hang if you attempt to upgrade an entire release using it - but it is capable of downgrading parts of your system to match up unusual RPMs. Of course, if you stick "odd" RPMs into your system, you will have to remove them before attempting to upgrading to, say, Fedora Core 7 if you wish to retain your sanity. Package dependencies are a simple mechanism to tell you what a particular package needs. Working out all the kinks requires some pretty good graph code.

I've run RPM-based and DEB-based systems for many years. I've never hesitated to install from source if there is no RPM available for a particular package. You only break your packaging system if you overwrite the libraries under RPM/DEB control with newer ones. Almost all source packages install into /usr/local by default and will not (normally) conflict with anything you have installed from your distro. If you wish to be really paranoid or you know that there will be problems, you can always install into an entirely separate directory tree (such as /opt).I do this for 2.3.x development versions of the GIMP, for example, where the development libraries *might* conflict with the installed GIMP 2.2 ones.

Of course, you can be smarter too - you can go the next step and actually build packages for your system. Many packages have .spec files around. Similar instructions are available for DEB packages too. checkinstall can be used to tag files from a source install, making it easier to pull the files out too.

Cheers,
Toby Haynes

I think now redhat 7.x to 9 versions and fedora core 1..4 users are left without a choice
First they have to fix that before the rpm rewrite

http://www.internetnews.com/dev-news/article.php/3 649081

and the future seems to be smart http://labix.org/smart

The Smart package manager http://labix.org/smart is a much better choice in my opinion. It is a lot faster than yum, much more use friendly than yum. I have used yum and apt for many years but now that I use Smart I will never look back, unless something drastically changes with yum and apt.

Do your self a favour and take a look at it, you'll be supprised at how nice it is.

I'm not exactly sure that all of the complaints about RPM really stack up. RPM by itself is not inherently broken. It's actually a solid format for distributing source and binary software.

I think a number of the early complains about RPM stem from Red Hat's initial lack of a solid package dependency resolver and downloader like apt for Debian. In recent years this has been addressed by the likes of Yum and the very promising Smart package managers.

I have yet to see a trully perfect package management solution, but RPM certainly has some strengths over the options currently out there. Yes some pacakage maitainers can do a bad job at stating dependencies but this is more of QA issue than a problem w/the RPM format.

All Linux distros, other Unixes and even Windows suffer from some form of dependency / DLL hell. I think we really could set Linux apart or at least a distro apart is by coming up w/a small set of pacakages that constitute a base system and keeping them stable for a number of years. This is one of the areas that makes Windows look "more compatible" than the 20+ top Linux distros. This is what the LSB specification intended but mostly failed to do. Almost all Windows software is available for the two most popular OS releases (2K and XP) but in Linux it's all distro-specific, which is a shame.

Here's an example of a all too common disappiontment:
My boss installed a Linux distro the other day on his desktop. This was his first Linux desktop coming from a Windows background. I walked into his office and saw Firefox open to the Evolution website. When I asked him what he was doing, he said the distro had come with Evolution 2.2 and the latest release was 2.8. He was just trying to update Evolution. Well, anyone else tried this on a "packaged" Linux distro? You need to rebuild it from source, plus about 15 dependencies including a newer releaes of glibc. It just doesn't work "out of the box". We need to establish a flexible but solid base system so that people can just write software that JUST WORKS for GNU/Linux. This idea of having to get a 3rd party package built for YOUR distro is just a waste of everyone's time.

use smart package manager http://labix.org/smart. it will download things in parallel, supports multiple mirrors, package dependencies, and additional repositories http://en.opensuse.org/Additional_YaST_Package_Rep ositories, all much faster than yast/zmd whatever they're calling it these days.

I'd suggest you try again Suse 10.1, but this time throw the zmd/zen and all the Mono crap that Novell is putting on Suse right into the garbage can as quick as possible. Then, install Smart:

http://labix.org/smart

You're good to go. No dependencies problems, no hassles to install multimedia packages, no trouble updating. Works very nicely for me, at least for now ;-)

All right, Novell, here's my contribution to Open Source and Suse in particular:

I just tell everyone to get rid of the zen/zmd crap and install Smart ( http://labix.org/smart ). This way, they can also enjoy one of the best distributions available today, only held back by your stupid screw-ups.

Use the Smart Package Manager. Better than apt, supports APT, YUM, RPM dumps, YAST, Red Carpet, yadda yadda. All kinds of package management schemes. Integrates them all, handles complex setups better than APT, and can easily be used to upgrade distributions.

Use SMART. It works great.

I've used FC4 successfully to do cross platform development for mobile phones.

I tried to move to ubuntu, but it was missing some old versions of libraries* ... maybe they're around somewhere, but nobody was able to help me, so I aborted my switch attempt.

I 'poo poo' all those 'rpm hell' comments. I use the 'smart package manager' and have no problems, ever :

http://labix.org/smart

Unlike apt-get, it's able to install packages of multiple architectures too (useful for AMD64).

* I'm running FC4 on AMD64, so perhaps that was an issue too - I forget exactly.

Install SuSE, and use The Smart Package Manager.

On SuSE, the only thing you cannot install via Smart is support for encrypted DVD playback. That's the one time you'll have to use the commandline, to run this shell script, which automagically downloads/compiles it for you.

Everything else, included the ATI/NVIDIA drivers, can be install via GUI, and configured via GUI.

10.1 just came out. It's super slick. Give it a try.

I think the latest versions of apt do support multi-arch. Apt is much faster than yum. What the cool kids are using now, though, is smart.

Huh?

Smart supports 64-bit architectures, and mixing of 64-bit and 32-bit applications/packages. Smart also supports apt-rpm repositories.

I use it all the time ;-) I honestly had no idea that you couldn't mix them. Take a look:
http://labix.org/smart

SMART Package (meta)-manager is kind of nice.

Add in YaST repositories, APT, YUM, RedCarpet, or just dumps of RPMs, DEBs, whatever. Add in all the mirrors you can think of (it automatically prioritizes them by download speed). I find it convenient to also have a local "RPM" directory, where I drop random packages that I want to install. This is my local "repository".

It's slick, it handles conditional dependancies nicely, and it doesn't choke on "broken" systems the way apt does (sometimes you WANT to leave your system partially broken, the SuSE pygtk2 nonsense comes to mind). It's not _yet_ production quality, but its pretty damn good. I expect a lot out of version 1.0.

Oh, and if you want to install from source .... get checkinstall, and possible Kommander (latter is buggy). Checkinstall does ./configure, make, and make install for you, but does it in a chroot, and then builds an RPM. You can then manage this RPM like any other.

Pretty slick, huh? Kommander is a GUI front end, which relies upon checkinstall.

http://kde-apps.org/content/show.php?content=13134
http://asic-linux.com.mx/~izto/checkinstall/

The other nice thing about smart: with basic options, its just like synaptic or kynaptic, but "slicker".

I digg it :)

> ...If you're your new to Linux, I'd opt for trying both Unbuntu and Fedora Core, to get a feel for RPM and DPKG based environments).

I would advise immediately installing the smart package manager on which ever distro you use. Makes package management so much easier than either of them, IMO - esp. if you have an amd x86_64 (since it can handle having packages from both x86 and x86_64 installed at the same time).

http://labix.org/smart

At least in the RPM world, one would be neglect to not mention red-carpet and smart, IMHO the two best package managers out there. Although red-carpet has morphed into Novell's ZLM package, it is still the best system for enterprise Linux patch management, even if you use RedHat or some other non-Novell distribution. Smart is still in beta, but it is currently quite stable and functional even in its development state. Smart is definitely the next gen package manager, taking all the great features of apt-get, red carpet (short of the server daemon), and others. It's dynamic mirror management and repository agnositicism (you can use Fedora, Yum, apt-rpm, YaST, red-carpet repositories, and even mix and match as necessary, provided they are all for the same distribution) make it extremely compelling. I highly recommend you check it out. http://labix.org/smart

We already have _several_ package management schemes that work across distributions AND desktop environments.

Autopackage is extremely user friendly, for example.
Apt works most everywhere (deb, rpm, tgz distributions)
SMART takes that integration work to another level (http://labix.org/smart)
klik:// is super-duper friendly for end users, and even with the K its being taken to gnome.

We don't need new technology. We need the existing technology to be made more wide ranging.

SMART builds on RPM/DEB/APT/TGZ systems, abstracting package management at a high-level. You can still use the 'older' tools, however. Think server.

klik:// is far easier installs for the end-user, and the klik:// architecture is mostly distribution agnostic.

Autopackage is very intelligent about putting whatever is needed whereever its needed, and fairly distribution agnostic.

The job of the LSB should be to push these standards, and make documentation avaliable so that these tools can work everywhere. Also, to make it _far_ easier to build packages that autoconfigure themselves for any distribution, and correctly setup dependencies for the appropriate package manager.

The best thing about building newer package management tools on older framework is that you don't have to change anything; you can keep doing what you are doing, or you can move on to the 'smarter' tools. If you build a flexible enough API, it doesn't have to be targetted at _any_ framework. You build tools into the desktop environment to support whatever package management scheme you could possibly desire, or you just rely upon integration with older standards to remain sane. In fact, proper standardization on flexible package management could actually encourage MORE variety in Linux desktop environments. If there's a standard way to handle installed apps and dependancies you don't have to do as much work in your desktop environment.

Flexibility thrives in an environment of sophisticated, easy to use tools. Look at all the work distribution creators have had to do to get their gnome and KDE to 'integrate'. If both can suddenly hook into a distribution agnostic app management system, you can provide more choice in environment at a far lower integration cost.

Regarding desktop/server distinction; that's simple. RPM/APT whatever isn't going away. The newer 'layers' are RPM/APT aware. Server/Desktop common software is managed at this level, using RPM/APT. Other utilities build on top of these; they transparently manipulate RPM/APT, using pretty GUI one-click install tricks, this, that, and the other. The only 'separation' is increasing layers of complexity.

Really, the only thing that will go away is unmanaged source-installs, because they really don't make any sense. It's very difficult to manage source-installs in a package managed world; there are a few utilies that will 'wrap' sourceinstalls into an RPM or a DEB, but you still have to do dependencies and the like by hand. ./configure, make, make install time has passed.