Slashdot Mirror
APT - With Your Favorite Distribution
Then there is another solution from Connectiva in Brazil, which has made something called APT4RPM -- basically an APT wrapper around RPM database on your machines, so you can use all of Debian's APT features (sans DSELECT feature) to upgrade your packages, or your entire distribution. (So now you can use your favorite distribution AND APT to update it.)
Two open source developers have improved Connectiva's solution to work with ANY RPM-4 based solution, and the [not finished yet but seems pretty stable solution] is at APT4RPM project pages in sourceforge. I have decided to give a test on my Redhat 7.2 machine. I installed the binaries, edited the /etc/apt/sources.list (just remove the # from your distribution's mirror), typed "apt-get dist-update," crossed my fingers -- and lo and behold, 48 new packages were installed, 7 were upgraded, and I only had to press "enter" to start the ball rolling!
So, for those of you who want to test it -- the URL is above (and if you could help with creating mirrors for your favorite distribution - that would be very helpful, thank you), you might want to try it. Just don't forget to read the FAQ before doing anything, and report bugs to the authors. Note: although the binaries are for Red Hat, the SRPMS are right there so you can just recompile it on your favorite distribution. Enjoy.
rpm -Fvh slackware.rpm
Here comes an example from the real world: Apt/dpkg is no better than rpm. I can install cups without ghostscript and apt doesn't complain. I have this dependency with my printer, most probably others who use CUPS with a laser printer don't have the dependency.
.SPEC file said so.
I don't see any problem here, either. All the dependency "problems" I can imagine can easily be solved by a flatrate, some time and a big harddisk.
On SuSE, I often used --nodeps for rpm, cos I *knew* that mutt doesn't *require* a spell checker, even if the stupid
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
Instead of whining, I've decided to merely let someone else do it for me.
/. anymore. I think that instead of writing everything out, we should recycle electrons and just use links to what someone else already said (especially if they got +karma on theirs, then you can karma whore while not being original!)
Personally, I dont hear too many new comments on
Some mention of GNU/Debian would have been nice as all apt4rpm is doing is adding the functionality that debian already has.
For apt to work to it's full potential you need a have a list of all available packages at the time in the current archive. Which debian has, so the question is how many of the other distros are doing this to make sure all the dependencies are currently in check? Cos I can see a lot of conficts to be had if there isn't one or isn't done properly.
*shrug*
could this be what converts the hordes to linux? everyday you see it become friendly and more open to the newbies, now all you need is start button, a windows update icon and a blue screen of death.
From slackware complaining that it's missing every .o file on the planet, to Red Hat bitching that I need a new version of RPM (and the new version of RPM telling me that I need another dependency... and so on) I've seen it all. But I hear there's this new Linux XP® coming out that'll solve all my problems! All I need to do is upgrade...
It would be great if they had something like a P2P scheme for patches, and new modules. Imagine if even 25% of Linux users took part in it. Always-available high speed files of any type you need.
Job? I don't have time to get a job! Who will sit around and bitch about being broke and unemployed then?
RPM, on the other hand, specifies extremely inadequate information to support such a tool without a lot of extra hacking. The RPM format at best only provides the name and major version of any dynamic libraries a package requires. Since different distributions and upstream authors all seem to have their own ideas on how to use dynamic library versioning, this quickly degenerates into the dependency hell that anybody who has tried to install or upgrade a reasonably complex program like GNOME on an RPM-based distro has probably encountered at least once in their experience.
Instead of dragging our feet with RPM and all its drawbacks, why not just move distributions over to dpkg/apt/DEB management like Debian, or FreeBSD-style ports? It is all free software, and there should be no problem with licences or any political bollocks. The rotten RPM format, which has somehow managed to become the Linux standard, is a monstrosity only beaten in kludginess by Windows' inept software management system, and with the MSI package format introduced with Windows 2000, even Microsoft is making RPM look crappy. Leave it behind, and move to a better system.
Loneliness is a power that we possess to give or take away forever
I've been using this on Solaris for a few months and it works really well. There are certainly some code maturity issues but it is incredibly useful for serious system administration.
Austin Murphy
amurphy@nbcs.rutgers.nospam.edu
This was one of the reasons I moved to slackware. Virtually no package management. You want software? Get the darn tarball and have at it. Configure will tell you if you don't have the right dependencies. It has worked wonderfully for me. Yes, I know of the disadvantages of slackware's lack of package management. They are smaller than the advantages, imho.
On that note, I think since Slackware pretty much starts at nothing in the PM arena, it would be a great candidate for some kind of apt-get-type system. But that would, after all, pretty much collide with slackware's motto of being kept exceedingly simple. (Almost to a fault, some might say.)
It has no problems with dependencies, because anything needed is download right then and compiled from source. It also can uninstall.
And here is the shocker... FreshPorts.
Too bad its all under BSD liscence.. cus now M$ can use all of FreeBSD's port system in Windows XP 2005+ Profestional
There is nothing wrong with RPM. Unless you are an absolute moron.
First of all, this is oooold news. Connectiva has been around for a while, and they've used apt-get with RPM all that time. 'apt-get' was coded to be relatively package-manager-independant, so it's no surprise that another distribution has adopted its use.
Anyways, to my main point. You're *still* going to have dependency problems. This isn't a magic wand. It works well in Debian because a) there are hundreds of mirrors, they all carry the exact same packages, and they're all administered with a decent degree of competence. And b), the Debian packagers *care*. The packages install so easily because, generally speaking, Debian Developers arn't lazy. In fact, following the Debian Policy(a big reason why packages under Debian install and work so well) is actually kind of a pain in the ass. But it's still followed.
Yeah, apt-get is great. But it's just a tool to deal with packages. If the packages it's dealing with are crap, then it won't help you one lick. Most Debian Developers take care of a *single* package. There is a decent minority that takes care of a number of packages each, and there are a very very few that take care of dozens of packages each. And these people *use* their packages; they use the apps they package, they use Debian, they use their Debian packages.
Can you say all that about Red Hat? How many thousands of packages do they have, and how many package maintainers? A few dozen? Full-time? That's being optimistic. You're still looking at a stunning lack of man-power(when compared with the alternatives).
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Back in August I decided to give Debian a try. I downloaded the apt and dpkg SRPMs from Connectiva and installed them on my Red Hat 7.0 system. It took a bit of shoe horning to get them in, but I made it happen and they worked.
Then I went into the /etc/apt directory and pointed everything at the Debian archives instead of Connectiva. At first I tried to just aim it at ftp.redhat.com and update my 7.0 install, but apt and the Red Hat archive didn't like each other. Anyway, I ran apt-get update and got the Debian lists, then was able (with a lot of manual this-and-that that I really should have documented) to apt-get dist-upgrade into Debian stable without rebooting.
Since I was dialing up at the time, it took a while, like a week or so, just to download it all. Once I got everything installed, I let it run for a while for shits and giggles. For a period of almost a month, I had a couple of virtual consoles logged in, a couple displaying Debian's /etc/issue and a couple displaying Red Hat's /etc/issue. Then I decided to do the kernel, too, and rebooted.
I'm still finding a bit of Red Hat cruft now and then. Oh well.
I like to play children's songs in minor keys.
"We're all sons of bitches now." --J. Robert Oppenheimer
What you've said is the true power behind Debian. It's not really apt, as everyone likes to claim. It's in the social structure behind it. The policy and the extensive testing of each package makes the system work together so well to get rid of dependency problems. The fact that you've got maintainers looking after their individual packages and an open process with strict guidelines forces everything to behave.
Sure, dependency problems happen, but far less often than I ever had to deal with in Mandrake or Redhat, and when they do happen they are fixed very quickly. How many times have I seen in the unstable changelogs on entirely new package uploads with the only change being some minor dependency problem which hadn't affected me?
The fact is, Debian's social structure is what gives it its power, not the tool it uses. While apt is a powerful piece of work, it's the community that gives Debian that special glow that all these other distros are trying to emulate.
"I may not have morals, but I have standards."
I'm very pessimestic about using auto-update tools. In fact, I dispise most install tools. I remember DOS being easy - one directory for pretty much everything to do with the OS: C:\DOS. Simple? Yes. Organized? No.
So I'd end up with C:\DOS, C:\APPS, C:\GAMES, and C:\P0R... umm.. forget that last one.
I guess I just have a thing for knowing exactly what is on my system. Waste not, want not. I still remember having to carefully pick and choose to get what I wanted on my 1.2MB drive. Most distributions seem to treat harddrive space like water. All this in the name of compatability?
Back to my original point, about not liking updaters... I don't like the abstraction of chooing an app and letting it install it's dependancies itself. Yeah, that's a nice thing (and probably the best for the end users) but why can't I just have a nice page saying something like: "you need these packages to [install|use|have sex with] this package"?
Meh. I'm probably too anal retentavie on this issue, but when I look at the filesystem I do not want to be saying "what the hell is that?".
I guess I've been burned one too many times by updaters that accidently install older modules over newer ones simply because it didn't "know" better.
Incedently, I really like the Windows XP driver protection thing. To sum it up, if you attempt to install a non-certified driver, a dialog essentially tells you that 'installing this driver may f**k up your computer. Install anyway?" (Am I the _only_ one who thinks that this was the original, developer, text for that dialog? hehe.)
Nevermind me, I'm just an incoherant babbling idiot. Move along.
Price, Quality, Time. Pick none. What, you thought you had a choice?
Rpm is getting a bad rap because it is actually a bit more flexible in practice: because it uses file dependencies extensively, you can, in fact, install rpm packages on systems even if you don't have a whole dependency infrastructure built around them or if some of the files come from manual installations. That's why so many more RPM packages are distributed on people's web sites than Debian packages. But this comes at a cost: as people try to do more (uncoordinated packaging), more things can go wrong. Some of the combinations you might want to install are simply impossible. With apt, you wouldn't even try because it's not a choice. With rpm, you can try but it fails, and rpm is then blamed for the failure.
If you could build an infrastructure like the Debian project around rpm, I expect it would do just as well as the apt/deb mechanism (the automatic download managers already exist).
I use mostly apt/deb right now, but I have also used rpm a lot in the past. Altogether, I think neither rpm nor deb/apt have really solved the packaging and system update problem completely yet. They are both rather imperfect solutions, each with their own advantages and disadvantages.
I've had the same Slackware system running on my home desktop since 1996 and run about 12 Slackware servers in production. I've never had any problems (other than in the pre-glibc days, ugh!) with getting anything installed and running on any of them without any fancy package managment stuff other than pkgtool. In the same space of time I've also had 2 or 3 Redhat installations and one Debian installation get so completely fouled up in the package management that I fixed them the MS way, just gave up, reformatted and re-installed. I honestly think package management, at least the way it stands with apt and rpm today is more problems than it is worth.
Although software writers need to be more versatile at this... I think I have 3 (yes, three) versions of QuickTime installed on my Win2k box. Why? Cause some programs are too stupid to know if they can utilize a new version or not. Actually, QuickTime is the only program off the top of my head that I can remember that is pretty bad about this.
Is your son obsessed with "Lunix"? BSD, Lunix, Debian and Mandrake are all versions of an illegal hacker operation system, invented by a Soviet computer hacker named Linyos Torovoltos, before the Russians lost the Cold War. It is based on a program called "xenix", which was written by Microsoft for the US government. These programs are used by hackers to break into other people's computer systems to steal credit card numbers. They may also be used to break into people's stereos to steal their music, using the "mp3" program. Torovoltos is a notorious hacker, responsible for writing many hacker programs, such as "telnet", which is used by hackers to connect to machines on the internet without using a telephone. Your son may try to install "lunix" on your hard drive. If he is careful, you may not notice its presence, however, lunix is a capricious beast, and if handled incorrectly, your son may damage your computer, and even break it completely by deleting Windows, at which point you will have to have your computer repaired by a professional. If you see the word "LILO" during your windows startup (just after you turn the machine on), your son has installed lunix. In order to get rid of it, you will have to send your computer back to the manufacturer, and have them fit a new hard drive. Lunix is extremely dangerous software, and cannot be removed without destroying part of your hard disk surface.
SuSE with their YOU (Your Online Update)
YOU == YAST Online Update
Thanks for the easy to follow bit. Often install info, practical things, are glazed over. I use SCO because I'm so rich, but I see the value of the post.
I heard awhile back that Apple and the FreeBSD, NetBSD and OpenBSD teams were working together on a unified BSD packaging system derived from ports and apt that would allow packages to be installed across Darwin/Free/Net/OpenBSD. Anyone know what the status of this project is? Does it look like it will actually be adopted in favor of ports? Will there be a Linux version too?
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
the thing which makes apt really cool is not because it's using debs instead of rpm's.
;-)
It's cool because
1. For debian testing/unstable you can get daily updates to your system. For stable you can get daily security updates.
2. You know updating your system will be a simple, painless and easy process. You know it will automagically work after two shell commands.
3. It is much more configurable than most RPM interfaces.
4. There is usually one "kind" of debs, which come officially from Debian.org, instead of a million different RPMS for Redhat/Mandrake/SuSE etc which conflict with each other
5. You have almost everything you need. If you use "unstable", you will always be on the "bleeding edge" with not too many problems, rather than waiting for distros to release their latest CD, and then sometimes trash the whole system because of a failed upgrade.
6. And of course, without the dependency hell!
As you see, dependency hell isn't the whole reason why people prefer apt above RPM based systems. Before they solve these problems, debian/apt will still be my first choice.
Don't quote me on this.
Question: I want to update my KDE (from the default Redhat 7.2 distro) and I've never had success when I've tried downloading all the rpms manually and trying to solve the #&#*@ dependencies...as a new user of apt4rpm (and, yes, I looked through the man page and FAQ) will apt4rpm automate this? If so, what do I need to do?
-- @rjamestaylor on Ello
isnt red hat trying to make money off this too?
Ever noticed that if you build the app from source you don't have all the dependencies you do from the rpm. Oh sure there are some build dependencies and of course You can't install a perl program and expect it to run on a box that doesn't have perl. The rest. Well they are intended for one purpose only. To sell you the latest version of the release. Why can't I install the latest KDE on my box when it's been built and released for one version up from me? Simple if I do. I might not by the disks for that version. If they built rpm's that were compatible with another distro then they run the risk of having you buy the other guys distro not theirs. Ever wonder why you can't install the Netscape rpm's without index.html?, but if you go to netscape.com and download the installer you don't need it? Or why if you put a redhat rpm on a mandrake box it looks for a redhat rpm and ignores the fact that you have that lib under a different rpm name? I build rpm's for a living and basiclly it comes down to this.
.gz files as easilly as before. So much for that. Ximian, up2date etc. are a great way to make money off of products that essentially are the same(the distro's). The only question I have is, why can I install Windwos + Office on a 2 gig drive and have lot's of room for data, but I can barely get Mandrake or Redhat to fit. Talk about bloat. Which is why my Libretto runs FreeBSD and X. Dependencies are creating a bloat situation of immense proportion.
1. Distro created dependencies 75%
2. Dependencies created by nameing conflicts 15%
3. Real Dependencies 10%
Time and time again I've downloaded and edited the src rpm opened the spec file and found that SPECIFIC distro rpms are listed as dependancies rather than the dependencies created during the rpm -bb command. Thereby making sure that an RPM from distro A won't work on distro B. What really sucks is now that ATT has put me on a 56k cable modem I can't get the src RPM's or
I'm sorry, I'm to tired to be witty at the moment so this message will have to do.
Debian unstable has all of the latest packages a mere "apt-get update && apt-get upgrade" away, including kernels 2.4.x, evolution, KDE 2.2.2, nautilus, etc. The main reason for the "unstable" label is that they don't support it as a release, but in my experience Debian "unstable" has always been stable enough for desktop use. (This is not to be confused with Debian's "testing" branch, which is, er, messy :-)
For servers and workstations that require high availability, though, you don't use the latest version of anything. Ever. Debian stable, while certainly not the bleeding edge, provides a set of software that has been proven by time and experience to work. And the latest security fixes are always available from security.debian.org. Debian stable is exactly what is needed for a production environment.
People who criticise Debian releases for being out-of-date need only look at the numerous security and stability issues Redhat and Mandrake have to suffer through in order to maintain currency. Debian provides a stable, proven base upon which you can easily upgrade to the latest "unstable" branch if you feel like you need the latest toys to mess with.
Loneliness is a power that we possess to give or take away forever
The wonderfulness that is apt-get, and the dpkg engine that it runs, is two fold:
o apt-get install galeon. Yes to install deps, blam! done.
o The true reason people love it so, and the reason it Works, is mainly due to the hard work, sweat and tears that the package maintainers put into each package. Each maintainer generally only handles either a single package, or just a few. With the 7-8k stable in all but name packages in Woody/testing, this represents a truely huge effort.
Not to belittle other distributions, but Apt has a huge advantage, solely due to the sheer amount of people hours that are put into tweaking every little package until it is just right. For a comercial distribution tho, this is cost prohibitive, and one maintainer must be responsible for many many base packages. The debian maintainers also QA addtional packages, so users arn't so much at the mercy of the setup that the origianal external software authors used.
I hope I don't come across as too much of a zealot, but it is really really really nice.
~.~
~.~
I'm a peripheral visionary.
We have a better-integrated system, is what we have.
:) [and come to think of it, so are all the rest...]
Our packages conform to a tight set of standards regarding how they're built, how they're configured and how they fit into the system. Our packages have more detailed information on dependancies, and a friggin' sweet install-time configuration system (no, RPM's %postinst doesn't cut it). We have functionality built in that other distributions need 3rd-party add-ons (ie. Ximian) for.
Also, you need to get over the what's-in-a-name thing. Our "unstable" branch could be called "kickass" or "foobar" -- the name would have just as much meaning, and it would still rock.
Okay... still not convinced? My employer puts out a highly specialized RPM-based distribution. Guess whose packages we base our distro on? Not Red Hat -- Debian! Their packages tend to be more current, more portable (Debian does their patches right), closer to the filesystem standards we comply to, and otherwise All Round Better.
C'mon... try Debian... just for a month... the first hit's free!
this is really cool.. but why not just use debian.. then you can have your cake and eat it too.. or in this case, have your software and great package management too..
this kinda seems like a lot of work to get packages if you are using redhat or mandrake.. it would be quicker to get rpms from the millions of places that have them then from the feel places that will have debs for mandrake or redhat et al..
if you want the great package management of debian and the great new desktop managers and stuff of mandrake, just install debian and switch to unstable and apt-get all the stuff you want..
Why not just use Debian ?
It's amazing how this technologically superior distribution gets ignored all the time because it doesn't come with (insert fancy feature directed at newbies here).
Also since debian has the most mirrors, it's very easy to apt-get your deb-s in any part of the world.
Now what do they have?
Correct me if I'm wrong on any of this, but:
- a 3-month testing phase before any code is released to the world as being "stable"
- dselect
- the best distro name
- speaking of which, a name that inspires trust from it's user base. It has the most stable "stable" out there.
- it's the first (and only?) linux distro NASA's used in outer space
- the only distro out there that's looking towards alternate free kernels, with an experimental GNU/Hurd distro available.
- the most flexible default linux configuration
Keep in mind there has been little interesting white culture for 100 years. Jazz, rock n roll, hip hop, leaning toward music, have a resolve and importance unmatched in euro-bread snoozeries. Food is another point, as carribean and asian cuisine has had a more powerful role in the last 25 years, with the exception of French food.
Ever been to Europe? Probably not. Attend University? Probably not. You will be forgotten in shorter time than you lived so callously.
I wanted to know if you install something using
./configure
make
make install
Is there anyway to uninstall it?
make install && echo "Yipee\!"
A little OT I guess, but whatever.
:-)
After yesterday's article on making linux too hard, I went and grabbed the kpackage alternate for dselect. I've got to plug it, it was a bit slow and ate up the memory, but it shows a lot of promise as a great replacement for cufty dselect. I know there's a bunch of other potential heirs to the throne, but hopefully no one will ever have to use dselect again! It is a major barrier to entry on debian (even if it is powerful) and something a little more user friendly will do a world of good.
Kpackage isn't quite ready (it crashed on me a bit) but it's showing a ton of promise, and I'd bet the others are too. Once we toss dselect, it'll really be a major event for debian. Between that and the new installer I can't wait
"I may not have morals, but I have standards."
Use a script or scripts -- keep an up to date
list of the ftp-accessible RPM
resources for your distribution. Use --test
with rpm -Uvh and when you have a
dependancy -- just grep your list(s) and
wget anything you need. In all, it keeps you on top of
what is going on with your system.
Not hell at all, IMHO.
I will share the scripts I use for mandrake if anyone wants them.
The RPM format at best only provides the name and major version of any dynamic libraries a package requires.
.deb you never bothered to explain what that was. I rather suspect it's because Debian doesn't have the equivalent of SuSE: if you install a .deb package, you can be 99% sure that the guy who made it was using Debian.
.RPM file format... but it bugs me that nobody who marked you +5 seemed to notice that you never mentioned what this feature was!!!
You would perhaps like it to provide the author's favorite ice cream flavor, too?
Since different distributions and upstream authors all seem to have their own ideas on how to use dynamic library versioning,
Isn't this the problem entirely, and not the RPM format? If every library version number were updated the way it was supposed to be (backwards compatible in minor version number increments, API changes in major version number increments), then RPM works perfectly. I've seen it. Install version 2.3 of a library, and you can upgrade safely to 2.4 without breaking anything. If some bleeding edge packages needs version 3.0, then you install 3.0 *alongside* 2.4, and everything still works. Once the rest of your programs have been updated to use 3.0, you erase 2.4 and everything still works.
The big problem is what happens when this convention isn't followed, or when (worse yet) some library gets built into a FOO-bar.rpm by one guy and into a foo-bar-baz.rpm by another, so dependant software authors randomly choose one or the other, and you can't install both on your system. This could be solved if every author versioned correctly and every packager named correctly...
Or it could be solved the way Debian does it: with a single, authoritative package reposity. I occasionally have trouble getting a SuSE-built RPM to run on my Red Hat system. Debian users don't have this trouble, but if it's because of some superiority of
And don't get me started on ports. I play with alpha software and write C++, so I have a compiler and all sorts of header files installed... but you want to mandate that *everyone* have the same when they want to upgrade software? And enough RAM to compile it?
You could be right, of course.. there could be some vital missing feature of the
Read Guns, Germs, and Steel, if you can.
Take a look at the alien package ( apt-get install alien
It allows users of dpkg/apt to install Red Hat/Stampede/Slackware RPM packages by converting them into apt packages, then installing them -- version control is maintained within the dpkg system, and all the standard utilities (dpkg --listfiles, etc) still work. There's also an apt package for real's realplayer... you download the file from real.com, then use apt to install it -- no scripts, no junk.
The battle isn't RPM vs. APT, but in the implementation of and tools available for them. Alien makes RPM packages available under APT. Can i use deb packages under RPM?
What debian really needs to truly kick as is a *BSD-like 'make world' feature. We've already got all the source-build dependencies - how hard could it be? As it stands, you currently need to set up some bizarre build-daemon system to compile sources for your own particular subarchitecture.
There is a similar project, named apt-rpm. You'll be able to find more information about this software onto http://apt-rpm.tuxfamily.org
what linux really need is something similar to windows update but that also handled popular software in someway.
Some centralized server(s) kept track of everything.
You would go to linuxupdate.com and it would read in a file that listed everything you had installed, then would list any critical bug fixes you needed.
So then internally, it would route you to a free server that had what you needed and it would all download and install, then you'd be back at linuxupdate ready to pick any other software you wanted such as kde2 or staroffice or whatever, then you'd click "staroffice" and it would figure out what you needed and automatically download and install all of that stuff..
It would be simple and have a webfront end and would use something like apt to do the background work so that dependancies were never messed up and then everyone would be happy and eventually people would stop using windows and start using linux because it would be just as easy to use as anything else.
up2date was better than their web portal idea, but it was only a matter of time until competition came along.
If you need text styles to communicate then you don't have a message.
#netselect-apt unstable; apt-get update ; apt-get -yd dist-upgrade ; apt-get dist-upgrade
Actually, probably replace those semicolons with && so commands proceed only if everything is ok.
It's a good time to be a Debian user :-)
I just wish packages would install in a single directory, with maybe a few very clear exeptions. I'm sick and tired of having to hunt down bits and peices of a packages all over about a thousand different paths.
/usr/bin is disgusting.
The LSB just creates more of this hassle, not less.
Stick everything in it's own directory instead of litering the world a la c:\windows
and I'd be a much MUCH happier person. As would many others I suspect.
I want to see two things in `configure` - a 'make uninstall` target being mandatory, and having part of `make install` copy the configure.status (or whatever script it is that holds the current configure string) to somewhere. The 'package' (source tarball) need not be aware of the existence of this script, really, just that it exists automatically as part of the install. That way, I can run it with some target like --uninstall and remove the binaries/man/etc stuff, or drop it into the source tree when I download from scratch (and have removed the original source tree).
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
I know I will most likely be marked down for this, however.........its a flaw in open source.
You CAN'T do dependency checks accurately. Sure, with Windows you can check for the latest version of microsoft runtime libraries.......but, its easier........Microsoft is a closed-source system........they control the binary compilations......
For this reason alone, Microsoft and closed-source has a much EASIER time being used by the masses. Sure, you still get version conflicts, but I have not had one that I can remember in the last two years. Installers have now started checking version numbers, and they are getting smarter.
Linux will never get to this point while users are given the option of downloading binaries that may contain pre-compiled libraries from the application's developer........they could be a much older version, or some incompatibilities introduced.......but how would the system check??
The only solution I could see is a smart-dependancy checker that is able to get a list of specifications on the functions, and verify that each is there and working properly....and I don't see that happening.
www.atacomm.com - The Leader in VoIP Product Distributi
I've been using Debian for 2 years now (wow, it's been that long already!) and my experiences on the mailing lists were very different. The debian-user list is full of nice, helpful people who are very patient with users both new and old. They'll do their best to help you solve your problem, because they were there once too.
The debian-devel list(s) where the maintainers hang out are a lot tougher. They're not very nice to people who post inappropriately (i.e. if you don't know where to post, post to debian-user!) and they do have a low tolerance for hyper critical people, but they do welcome constructive criticism if it's polite, same as anywhere else.
I can't say I fully disagree with Elbereth's comments in terms of the developers, but I think that's a function of all the work they put in on a volunteer basis (thanks everyone!). I generally find that the difficulty of the package being maintained is proportional to how intolerant they are of clueless users, go figure.
The users are all very friendly and helpful in my experience though. The developers are also quite polite to people trying to be new package maintainers (the list for you is debian-mentor if you're thinking about this), so don't be too afraid to get involved. Just like anywhere else though, mind your manners and you'll be fine.
"I may not have morals, but I have standards."
So did I. And had enough of Red Hat and moved on to something better...much better and much more stable. SuSE
My major gripe about the way linux distribs work is that they like to install stuff right into /usr/bin and /usr/lib.
/usr/bin, /usr/lib etc etc and whenver i wanted to, just rm -rf /usr/local (or /usr/X11R6 for X stuff) and be done with it. Plus removing the /var/db/pkg (or where-ever the package db files are stored)
I'd enjoy it if the base system stayed in
-
ping -f 255.255.255.255 # if only
Everytime I read "flat rate", I salivate.
Why?
Because in this Gawd Awful Moslem Country - one that constantly labels USA as "evil" and Osama Bin Laden as "Holy" - that I am living in, there is NO "flat rate".
APT-RPM is a God-send.
Many thanks to the good people who carried out that magnificient task !
Muchas Gracias, Señor Edward Snowden !
Or, you could just do it all centrally. Have all the basic libs placed in a central location, and then have all apps dependant on those libs compiled from the centralized binaries of those libs, and placed alongside them in that central repository.
Then, all apps that depend on those apps will have to depend on the versions that are in that central repository.
And you could create a strong policy that all items in that central repository must conform to and give it a cool name and you've beaten your seemingly inherent flaw.
"I may not have morals, but I have standards."
Well,
You point out some Debian cons. I administrate quite a lot of Linux boxes, and have done for a long time. I would LOVE to change to Debian - basically because of atp-get and deb-packages.
However each time I try I come to the conclusion that Debian is just not ready for big time use - compared to my current Red Hat.
For example, it turned out to be *impossible* for me to track down official installation instructions for Woody. And with the lack of hardware probing you surely want instructions...
Debain users, feel free to flame me, but bear in mind that I would really like to switch to your platform - it just lacks some very fundamental details - like installation instructions...
(And don't point me to bunches of unofficial web pages, I went to debian.org and started browsing - that MUST be the way to do it)
Personally. I think linux distros are just making it worse. With everyone using their own library versions and core software versions that are different, user functionality is shit.
I'm going to reference windows for a second, DLL hell use to be a major problem, but now, people can install library's in their own directory, why cant we do this with linux? If you say disk space you should be smacked. Id rather have a tar of a pre compiled binaries and libraries and an install.sh script than to put up with the crap every distro is taking. You should be able to take any distro binary and move them between distros. Until the day you can take a program and install it on any Linux distro, it will NEVER be on the same playing field as windows.
Linus needs to step back, come up with a new layout, let people add modules, libraries and programs without this nightmare. The answer is here, but everyone keeps bitching about disk space. Time to move on folks, lets have a little data replication to keep the system working. The need for 20+ library directories is over, kick the old habit about doing the same thing the same way. DAMN It, are we going to have these same articles every 3 months, and just let some vendor talk about how his package installer will solve world hunger?
I have enough complaints about linux distros, but I take the quirks for software.
-
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.- Scott Adams, 'The Dilbert Principle'
Well, until I can get CVS versions of all my apps as packages I think I'll stick with Slackware.
Did you try the link that on the sidebar that said Installation Instructions on the main page? You know, the link right below the one that said Documentation?
They may not be woody specific, but they work just as well for woody as they do for potato.
"I may not have morals, but I have standards."
It is OKAY to have dependency problems, as long as the vender provides a quick and easy way to solve them, ie "click to download and install them for me" type app.
.rpm (or .deb?) from the same vender, you are okay. Every distro has some kind of auto updater nowaday, just run that and let the software work for you.
Things may get complicated when you are installing some software from src AND some from binaries, on the same system. But hey, you shouldn't play with the SRC if you are not prepare to handle the extra work to maintain your box.
If you only install
Codeala - Just another mindless drone
All the grumblings i've read here are solved with the BSD port system. The separation of base system and ports means you don't need to "upgrade" to -unstable (upgrade to unstable? chuckle... seems i do that every time i get a new copy of windows, but anyways), just so you can install the latest mozilla or xmms. I remember running debian a while back, and wanting to install gnome 1.2 (it had been out for quite a while at the time, like a year), but finding out much to my chagrin that i was going to have to upgrade my ENTIRE OS to this "unstable" BS. Huh? are you cracked? just for a new gnome? Gnome is unstable enough as it is, it doesn't need any more help.
Dependancy problems: no problem. Dependancies work exactly the same as precious APT. You can pkg_add -r to install the binary package and all the dependancies across the network (internet) if you dig binary packages, or you can install the port from source, guaranteeing it works with all the current libs on your system, and allowing you to make CHANGES to it, while still mainting the packaging system. Some ports even check for the existance of other ports while compiling, and add extra functionality/cooperation/integration when possible. Aha! Brilliant.
Ever see that error "this package requires lib.so.2.2 and you have lib.so.2.1"? pfft. When you compile the port from source, it uses the version YOU have installed, providing its compatible of course, obviously major version number changes aren't.
Apt is an improvement on an idea, ports is a whole new idea. Face it, ports may not be the most widely used, or the mostly loudly screamed about from the mountain, but it's clearly the best.
BTW, I am not some crackpot who has never used Debian before, this crackpot had debian installed for a good year before investigating FreeBSD....
Funny how Debian users attack RPM on technical grounds, and RPM users attack Debian _users_ on ad hominem grounds...
Maybe this says something.
Maybe it's not like this today (the last time I used Debian was over 5 years ago), but that one experience so long ago soured me on Debian FOREVER.
I pity you for your inability to look beyond a wild generalization from so long ago.
The Debian community is so passionate because it is a distribution supported 100% by the people, and only the people. There's no commercial entity that funds the Debian Project. The release manager doesn't get a bonus if he gets the release out ahead of schedule, and the QA team doesn't get paid to manage packages that fall through the cracks.
Every single aspect of Debian's development, support, and growth comes from people who care about it enough to contribute their time. Does this tend to breed fanatics? Quite possibly. Is it understandable? Certainly to me. I don't see such fanatical support of other distros, because virtually all of them are developed by a company, not by a community.
Now, if that's not your cup of tea, great. There are plenty of other distros. That's the whole point, after all. That's the beauty of Linux's "fragmentation" that has forever been a point of criticism from the commercial software world which is so used to not having a choice.
Will this new tool work with "alien", and be convertable to apt format?
I think it is unfair everyone can run this new wonderful tool but Debian users.
LinuxFromScratch 3.1 was released a day or so ago, and if you're still dealing with dependencies, hate the bloatdistros out there give it a shot.
These last few lines have been released under the GNU FDL...http://www.gnu.org/licenses/fdl.txt
Starz
Doesn't Gentoo Linux have a system such as this, which is compatible with the BSD ports system?
www.gentoo.org, I think.
A few months ago, I installed a fresh RH 6.2 system, disabled most all services, hooked it up to the net, and ran up2date. The next day I came back, it had crashed.
I ran it again, and watched the memory usage. On a 512MB machine with 512MB of swap, it used up *all* memory. Crap.
So I ran up2date, and picked just the new up2date package, started it, and left for lunch. An hour later, it had over 30 packages scheduled for download to satisfy dependencies, and was, of course, eating up hundreds of megabytes.
I FTP'd all of the 6.2 updates from RedHat, and (tried) to install them. Most installed. Once that was done, I was able to run up2date to get the rest of the updates to apply.
I didn't know that having a fairly "up-to-date" system was a prerequisite for running up2date.
steve
Oh, you're not stuck, you're just unable to let go of the onion rings.
Your gripes come from the wrong perception that it should be OK to install packages from one distro onto another. Mind you, it is not. There is no such thing as Unified RPM-based Linux Distribution Standard. Vendors are free to implement their own policies, naming standards etc. without consent with every distribution vendor on the planet. There are subtle points that package developers find important to reflect into dependencies. Of course, this can go over the edge -- I know mutt doesn't require that friggin' spell-checker to work -- but in general, I'd prefer to know what is required, and be able to bypass that, than to install packages in blissful ignorance and then figure out why it fails to function.
So if you need a package that is missing from your installed distro, but it can be found elsewhere, you cannot, generally, just bolt it in with 'rpm -ivh'. Instead, you could adapt its spec to your distro's rules, build from the modified spec, and probably upload your ported package to your distro's contrib FTP site. I did this many many times, and it's not much trouble, once you grok specfiles.
My exception safety is -fno-exceptions.
Well, it was KDE1, and it wasn't an issue with KDE, it was an issue with Qt. If you're going to hold an irrational grudge, at least get your facts straight.
And whenever you feel like being a little mature, you're welcome to apt-get install task-kde. KDE2 has always been packaged in Debian, ever since it was available. Debian resolved their concerns. Will you, or would you rather cling to your shortsightedness?
Like I said, Debian doesn't avoid these problems because of technological superiority, they avoid it because they don't have different groups of competing packagers. That's great now, but it'll be ugly if they ever fork.
This happened a few times. Connectiva, Stormix, Corel, all essentially Debian forks. Y'know what happened? Corel sucked (And nobody was surprised), but Stormix and Connectiva remained compatible. In fact, it was common for Connectiva users to upgrade straight from an existing Debian install to a Connectiva release, or vis versa.
Just because more than one group is doing the packaging doesn't mean they'll be incapable of following the same rules. That's why Debian works with 300+ people making packages, after all, they follow the rules.
For several years, Debian was plagued by packages with horribly broken dependencies. You'd install a package and this would cause a terrible, unrecoverable, inexorable, hours-long shitstorm of brokenness that sent many people to the store to buy a RedHat CD. I talked to this one guy at work who stopped using Debian in '96 and moved to BSD because of those problems.
In recent years, it's almost like someone went through, spanked all the naughty package maintainers, and told them to behave. And they did. And now Debian is really reaching its true potential.
I have watched it happen. After using RedHat for a couple years, a friend of mine finally convinced me to try Debian, and so I installed it one day after RedHat pissed me off for the n-millionth time with its own stupid broken packages. The install was a bitch and a half, and I had to install three times to get a usable system, but it's like riding a bike - once you do it right, you never forget. Debian is getting a new installer soon anyway, but I digress. The packages were mostly OK, but there were a few that just hosed everything else by nature of fucked up dependencies. Netscape was particularly prone to this in the unstable tree, but there were others as well in both stable and unstable trees. That was in '99.
Now it is almost 2002, and Debian has been devoid of these fuckups for a good year and a half, from what I've seen. Stable is *stable,* man, I mean like a rock! Even unstable is good. I raaaarely run into anything that's broken even in that branch!
If you used Debian before and threw up your hands in defeat because of fucked up packages, give it another try! It is *much* better now.
Yeah, God forbid a distro follow the bloody standard by having man pages where the FHS says man pages should go. And it's definitely too much to ask that developers of programs follow the same standard. It'll be much more fun to just do what the other guy's doing, and hope they don't change.
The RPM format at best only provides the name and major version of any dynamic libraries a package requires.
Er, no. To my knowledge, a package can rely on other packages or a library name - its nto limited to librayr names. Library versions are standard Unix versioning, and the lasic names `.so.3' don't change much across Linux distributions apart from how fresh the distro is - i.e, whether they are there or not.
You seem to be basing your rant on this misinformation so I won't bother to address the rest of your comments, suffice to say I'm running a fully packages version of last nights CVS GNOME and did not have to think about dependencies for any of the hundred or so packages that are part of it.
"There have been a few attempts to overcome dependency problems: SuSE with their YOU (Your Online Update)..." YOU stands for YaST Online Update, where YaST, being the SuSE setup tool, stands for "Yet another Setup Tool".
My approach to making a package format is running 'ldd' on every executable and then recording the dependencies, within the package. Any extra binary packages required (for eg. progs exec'ed from the application) can be entered by the user at the time of building the package.
./configure'ing it from source. I'd prefer an equivalent mechanism adapted into making a package and figuring out its dependencies.
This way, the package dependencies can be as trustworthy as
I've been a long time slackware user, and i'm so in love with autoconf/automake that i wish someone extended them to binary packages as well.
Sometimes, you're just not in a mood to compile the stuff up from source. I wish someone makes something out of this idea of mine.
Nikhil.
Debian (and deb/apt packaging) is successful because it is a community project. Thousands of people working in harmony towards a common goal, each doing their own small part with great care will always outperform a commercial effort. That's the core strength of the Open Source movement, minor politics aside. Does such collaboration always happen that way? Of course not. But when it does, it's a wonderful thing. And with the Debian project, it has. RedHat, Mandrake, et.al. have largely ignored this concept and this makes me rather leary. Corporations exist primarily to produce "value-added" products and services. Nothing's wrong with that. But you don't truly add value to Open Source software by packaging it in non-standard or inferior ways, especially when complete and superior distributions already exist. So why make your own distro that has all sorts of quirks and discrepancies? To trap less adept customers into needing your tailored support services for that specific distribution. And to familiarlize less adept administrators with supporting your own distribution's quirks so they don't feel like switching. Don't get me wrong, there's a huge market for Open Source support services. But breaking away from the community spirit and doing things your own way is not the way to do it. There is absolutely no valid reason for there to be so many distributions of Linux and related OSS. And there is no reason why Linux companies cannot just support community-based distributions like Debian and Slackware. Or maybe they're afraid they'll actually have to face competition in providing the best support services.
And now for some quick anti-Debian FUD debunking:
1.) Debian is not harder to install and configure. If you have problems with it, you're either using an ancient version on modern hardware (ie. kernel fixes since then) or you are missing basic requisite knowledge that you should have with any distribution. Glossing it over now with a friendly GUI isn't going to help later when problems arise or you need to do something more complicated with your system.
2.) Debian is not slow and it does not suffer because default packaged binaries do not use Pentium optimizations. The performance increase with architecture optimizations is negligable for most software. And Debian does make full use of other compiler optimizations that do not break compatibility with certain hardware. On the other hand, if you would like heavier optimization, (say, PentiumPro or Athlon) for certain packages, Debian source packages work almost as smoothly as the BSD ports system.
apt is good, but... there is nothing that even comes close to FreeBSD's ports collection.
The biggest problem with dependencies in RPM's is that there is a lot of human interaction required. I've seen A LOT of packages that require one of the following, thus causing a problem :
In each of these cases you have a problem. If I have Sendmail 10 installed and I'm installing an RPM that wants Sendmail 9, while I satisfy the requirements, it won't install. I'm not sure how debian deals with this.
If I have Exim installed, and I'm installing a package that wants Sendmail it won't install. Debian packages generally want MTA, a requirement which is satisfied by either Sendmail or Exim (or postfix for that matter).
If a package just wants a library without saying what package it comes from, apt is NEVER going to know what to install to satisfy that dependency without maintaining an Index of the contents of all packages.
These are deficiencies in the packages created by the package maintainers. There are other problems with the actual RPM way of doing things which are further compounded by the distribution builders.
A standard Mandrake install has about 30 packages as required that I have NEVER used. They are only required for certain circumstances, most of which I never needed. But I have to have that clutter lying around my system.
RPM is broken at 3 layers IMHO. The distribution builders, the package maintainers and the design of the application. Wrapping all of this in APT isn't going to solve anything. But until a viable alternative is marketted by someone with the power to drive it, RPM will remain the industry standard for commercially targetted GNU/Linux distributions.
Personally, I use FreeBSD and I love the make world solution for the base distribution and the ports solution for packages. This keeps me current, makes sure that all binaries are optimised to my processor and provides me with a one stop upgrade point. No hassles, no dependency woes and more time to get on with my job.
Hullo,
:)
Slackware was used by NASA at outer space, too
Cheers!
I hesitate to call myself a developer, but I have written and released (and abandoned) a number of open source programs. None of them have every been part of any distribution. My latest suite may require a kernel recompile, sorry but I can't avoid that (well maybe I can, I'm still working on it), should I not release my code til the support I want is in the kernel?
Barely finding enough time when I'm fresh and alert to actually sit down and code, document, update the webpage (Thankfully? I recieve hardly any email about my programs so I save time there), you expect people to install and check their software works under Debian, Red Hat, Slackware, Mandrake, SuSe?, Peanut, blah?
Sorry, I'm not going to do this. If someone makes the effort to email me with a problem regarding my software, I'll make the effort to help them. None of my projects are usless though, as I wrote them to do something for me, and spent the extra effort to "pretty them up" in case someone else found them useful.
Videoconferencing under Linux is not well established and routine, just perhaps the GnomeMeeting developers require something not found in GNOME 1.4, the same way it probably requires something not found in the 2.0 kernel.
If the developer doesn't make it clear what is required to install/run their software before you download it, that is certainly a bad thing, but isn't that something this new rpm-apt program will fix?
My recent problem was not too many dependencies but too few.
Recently, Mandrake added a kernel security update to their mandrakeupdate (urpmi) mirrors but placed a warning in the "details" section that states not to install the update through mandrakeupdate.
I'm not a total newbie but in an effort to bring my newly built system up to date quickly, I simply selected all security packages and installed them. Big mistake.
I know I should have known better but maybe there could have been at least one additional "dependency" to prevent users from using the wrong tool to install the RPM's for kernel updates and such.
You weenie.
I get printouts of the applications I want in binary and type the code in by hand in machine code. That's the ONLY way to update Linux. Screw that complex PM scrap... You can't get much more simpler than this, baby.
Heard of the Filesystem Hierarchy Standard? Evidently not. See here for a full telling off and here for further info.
__
Arse
When will Slackware be blessed with this apt-get?
./ earlier.
/etc /bin etc directory structure. Then i rm and tar would be my package manager!
Do we(Slackers) want it to be blessed? I've never used apt-get but all the debian people are so in love with it, so it has to rock?
But what is really needed is a sane directory structure for linux, as discussed on
Every program should have their own
Linux's only real deficiency compared to Windows for me, is that the software installation procedure (for new software) doesn't work with the same reliability or simplicity.
Apt and urpmi sound simpler... when they actually work, but if they don't, a lot more expertise than I possess is required to determine and fix the problem.
Commercial software like Kylix sounds very appealing, yet as part of my purchase decision, I'm forced to estimate my competence in executing its install procedure.
It is not urpmi's fault that most packages have dependencies missing. urpmi's capabilities compared to apt are very similar, and other than the fact that it doesn't work at all (at times when I have tried it), has no reason to be called inferior to any other solution.
SuSE Y.O.U. stands for YAST Online Update and... it's slashdot. I don't have to say what YAST stands for.
try gentoo linux http://www.gentoo.org It takes care of dependencies and is very up to date with packages. It even supports safe uninstalling of packages. Like ports only better.
Sure, it has imported some ideas from Debian (apt-get, alternatives) but current Conectiva is about as much a clone of Debian as it is a clone of RedHat ;)
Oh, and of course distributions like Debian and RedHat are also taking back in some of the work done by Conectiva. I guess open source must be working.
Damn, that's cool. I may have to install RedHat some day just to try that.
There isn't a dkpg package in Conectiva.
Conectiva is not compatible with Debian package
format and cannot mix rpms with dkpg.
>SuSE with their YOU (Your Online Update), ...
It's Yast Online Update!
I've always wondered why Slackware decided to invent their own packaging system instead of using Ports from BSD. Ports is the most awesome package management tool I've used. You get autodep handling/download install etc and you get that just compiled home brewed smell that you don't get with binary releases like DEBs and RPMs which slack and BSD users tend to like so much. ;) As I understand it Ports has already been ported to Linux so it would just be a matter of getting the specific ports together for slack. Slack and BSD are both very unixlike and appeal to largely the same type of crowd so it seems logical that they would feed off of one another's efforts when possible.
G. Washington on Government "it is force. Like fire, it is a dangerous servant and a fearful master."
Maybe it was (Po)lished Linux then, I don't recall. Either way, I got an apt and a dpkg RPM and went from there.
I like to play children's songs in minor keys.
"We're all sons of bitches now." --J. Robert Oppenheimer
would be an RPM upload checker...
When you create an RPM, and upload it to a central depository, the checker would verify that the dependencies your package points to, exist there.
If you have perl21 alpha on your system, but perl 6 is the only version released as an RPM for a distro, then either make a perl21 RPM and upload that as well, or change the dependency to perl6, and see if your software still works.
If distros chose to keep 3 branches of development, they could be renamed.
stable
installable, and
advanced
If a proposed package did not have all of its dependencies in stable and installable, it could not go into either of these upload trees.
Completely automated package management could be made on a system that installs proposed packages, either on a pure system maintained by a maintainer, or in the chaotic user space, where through feedback of the installer, users could report back whether the package actually worked with the claimed dependencies. Automated user feedback systems could decide what goes into stable. Dependency trees could list all of the alternative versions of a single dependency which work, not because the author or maintainer have tested all versions, but automated user feedback has determined what works.
Trolls/hackers who intentionally falsify claims of operation could have an impact, but if there are 2 claims of the same configuration. One works the other doesn't, there is likely a way for it to work with that configuration.
Hmm it seems silly to use Redhat with a hacked up apt, why not just get Debian - solve the dependency problem WITHOUT the bother of using a "hack" solution which may have unanticipated problems, and you get a better all round distrobution (FSH compliance instead of a nonsensical directory layout for starters).
It beats me why any Linux distros other than Debian and Slackware exist...
if the package is not on Ximian Red-Carpet servers (like, umm, KDE packages), you're (again) on your own.
This is a fallacy. Red Carpet also has channels for the distribution you're on. For example, I loaded up the RH7.1 channel, and saw that I could install kdepim from there, straight from Red Carpet.
Not everyone is honest, I wouldn't trust P2P for anything more than mp3's and girlie picts.
YUP from YellowDog gets my vote as an easy to use system. set it and forget it. Go get a scone and cup of Java. Read Linux urinal and your update is waiting.
photosMy Photostream
The spelling is Conectiva, with a single "n" because it is Portuguese, the language spoken in Brazil, and Portuguese avoids redundant letters. (But, of course, Portuguese has quirkiness of its own.)
I've never used it, but Conectiva looks like a good distro when you need to support users in the three languages it supports. The web site is in English, Spanish, and Portuguese.
From the English web site: "... the company provides consulting services, training and technical support in all Latin America through its own service centers and certified partners."
--
Senator Biden (and Osama bin Laden) say that the Saudi government cannot continue without U.S. support: What should be the Response to Violence?
Bush's education improvements were
# apt-get dist-update
E: Invalid operation dist-update
#
Did Connective change all the commands around or something?
Further down in this thread, someone mentioned the
Everyone makes a big deal about compiling from source in Slackware, or "not having a package management system", but completely ovelook the reasons why slackware doesn't appear to focus on package management.
- Slackware is as unix-like as possible. POSIX (correct me if i'm wrong) does not dictate any package management standards of any sort.
- Slackware's (very under-used)
.tgz package manager is simple and works with VERY few problems. It's similar, though not straight-up compatible, with the BSD packages and ports... The package manager is very slackful itself, and allows you to compile lots of stuff yourself without unnecessarily bitching about dependencies. Sure, it can lead to non-uber-developers missing a dependent library when installing something big, but they can go back and add that library either by source or by package, and all is good.
- Many RedHat-built packages (provided they're not built on GCC 2.96) work very well with Slackware, especially when converted to
.tgz using rpm2tgz or any of its accompanying tools. These tools allow you to have the best of both worlds (fully packaged software and a super-lightweight, nearly transparent package manager).
Slackware's developers follow the line of thought that package management is not and never will be an end-all solution to software installation on a *nix operating system. Instead of trying to force package management down the throats of their users, they prefer to take a split approach, giving some fairly good package management capabilities (also THE easiest to learn out of any linux package manager - it's SO simple) without discouraging source-compilation of software.forgive me if i've repeated myself a thousand times. i'm just ranting.
.... um, i lost you after "0110100001101001".
First Debian is ported to Windows. Now it's being ported to Red Hat? I'm so confused :-P
FreeBSD's ports collection minimizes this problem by being one coherent unit. I very rarely find a dependency that isn't automatically downloaded for me when installing a new port. The only downside is that it takes a while for the latest Linux applications to get into the Ports collection. If its something really popular, it gets ported pretry quickly.
I have to disagree with you here. I use inst & co. quite a lot (I admin a number of irix machines) and have very little good to say about it. It's may be a bit better than some others, but compared to apt/dpkg *or* rpm it's woefully inadequate. It's always a relief, after installing an irix box and weeding out the hundreds of unecessary fluf packages in the default install, to go back to one of my debian machines.
Version dependancies, for example, can be extremely confusing. If you have the wrong version of some eoe.* package for a package you want to install, it can be very difficult to parse the version info and jump through the necessary hoops to get what you want in place.
My biggest problem with inst, though, is that there is no effective way to deal with large numbers of packages. Sure, there are various keywords you can use, and they help, but they're basicaly a hack. Going through an extensive list (e.g., the freeware distribution, or even worse, the default install) and trying to prune out the stuff you don't want and/or put in the stuff you do want can be extremely unpleasant. I generaly find I have to make a large list, on paper, of the often literaly hundreds of package additions/removals, then use inst to implement them.
As everyone has pointed out, true P2P won't work because then you're at the mercy of whatever the next "Peer" decided to stuff into the "package" he passes you, which will very likely be malware.
But what about a 1/2 P2P network (P1/2P)? The packages come from peers, but there are one or more central servers with a database of packages and their cryptographic sums. You get the aggregate bandwidth of a P2P network, but the authority comes from matching the checksums of the packages against the master list.
For those of you running Red Hat Linux 7.2, you can now install and upgrade all the packages found on my enigma.freshrpms.net website by adding this line to your
rpm ftp://ftp.freshrpms.net/pub/apt redhat-freshrpms-7.2/redhat freshrpms
And now you can "apt-get install xine" or "apt-get install ogle_gui" or even "apt-get install gkrellm-plugins" with less hassles than before! ;-)
Of course, you first need to get the apt package from here.
Hoping some people will find this as useful as I do,
Matthias
So we have: 5467 source packges (8558 binaries), and 934 registred maintainers. I.e. 6 sources, or 9 binary packs/maintainer, rather than 1-2. Still not bad, though.
First 21 maintainer takes care of 30 sources packages or more, for a total of maybe 1000 (sources) packs. 144 maintainers care about >=10 source packs etc.
Now let's go and look at the bottom of the list:
270 maintainers with 1 pack
141 maintainer with 2 packs
...
While this is a great thing to have, the fact remains that it's the "top 50", or maybe "top 100" who make the most of the stuff, and each of these has a fair number of packs to do. Not that much different from commercial distros.
Try running Ximian Red Carpet without installing Ximian Gnome first, you WILL not be able to install Evolution 1.0, because the dependency information for a particular file related to k-pilot will not be able to be resolved. I installed Ximian Gnome manually rather than thru the go-gnome updater and now everything works fine. Evolution kicks ass...Red Carper kicks a lil ass, it does the job.
Ximian hosts all the packages that are included in your distribution. Including KDE. I've installed KDE with Red Carpet. No, really.
Now, why do package management systems succeed or fail?
All package management systems have two issues: First, figuring out which packages are needed.
Second, going out and downloading them.
The first one is a matter of a file format with metadata and then parsing. It can be tricky but it's basically parsing. The second is a server management and control-of-system issue.
Debian's system, like Ximian's works reasonably well because it's more or less closed: very few packages will ever require something that isn't in one of the mirrors.
Download a random rpm, deb, or tgz from the net, and who knows what you'll get. Maybe it will ask you for something that's in a mirror. Maybe it won't. If you're lucky, it'll ask for something you can find somewhere.
Aaron Weber
Technical Writer
Ximian, Inc.
Ports involves a fairly light layering of ordinary Unix tools to pull down "pristine sources" and manage the dependancies.
The Slackware "install it all by hand" dictum is fine if you've got one or two boxes; making it work for a set of systems being used for different purposes has got to be difficult to make scale.
Einstein said that things should be made as simple as possible, but not simpler. It seems to me that Slackware tries to head to that "simpler" point, which certainly suffices for a firewall box that shouldn't be running anything more than a bare minimum of services, but which oversimplifies for more complex systems...
If you're not part of the solution, you're part of the precipitate.
Tools that manage dependency chains, such as YAST, do solve the dependency problem well. YOU (YAST Online Update) is simply a way to obtain updates online -- virtually the same process is used to install from CD or NFS or whatever.
I discovered SuSE as I ran from Debian/dselect in horror, as dselect failed utterly to notice dependencies or install them. I am also a RedHat refugee, having bailed out of that scene around 2.1 and kernel 1.2 in the 1990s.
I also bailed out of the madness that is the BSD ports tree, in favor of YAST. I remain a strong FreeBSD advocate to this day, but for business use, I cannot maintain any unix as effectively or as cheaply as SuSE Linux.
This is not up for argument, this is my experience. I hope it is useful for someone as burnt by Slakware/RedHat/Mandrake/Debian/FreeBSD's proposed maintenance and update mechanisms.
Why do so many people complain "RPM makes installing from source hard"? Why all the -nodep?
One of the big reasons, may I say, is compiled-in preferences. IMHO, NO kind of reconfiguration of programs should require a recompile. WHY do we need to recompile at all - except for embedded programmers? Harddrives are cheap.
It is what configuration files are for - configuring the app at post-compile time.
"RPM can do some very handy stuff that DEB can't - like verify packages,..."
I have read that the dpkg based " debsums -a " is inferior to " rpm -Va ", but noone could quite explain why.
Anybody feel like going into it?
Novel theory: Modern Man evolved from psychopath
goto http://www.conectiva.com and take a look on the projects Conectiva has been funding
That said, isn't it completely possible to have APT play nice with BSD ports? i.e. I know apt can compile packages from source, this is where apt can fall back to ports, for instance. BSD also has packages (.tgz form) and a database for maintaining them (/var/db/pkg I believe). So I guess it's entirely possible to wrap APT around BSD's pkg_(add|delete|whatever). The BSD pkg_* tools are very powerful as well, since you can use regexps to remove/install a whole slew of packages, and other neat munchkin tricks. It's quite underrated, but that's kinda offtopic.
So why should you Linux whippersnappers have all the APT fun? :-)
FreeBSD has lots of utils to maintain ports (like portupgrade), but that just isn't quite as nice as apt.
The only problem I see is licensing (GPL vs BSD), but that's a whole different discussion I do absolutely do not want to get into (enough flamewars on FreeBSD-Current mailinglist already).
Heheheh, thanks for the heads-up. I should've guessed.. : )
Incidentally, does everyone with moderation points moderate while they're at +1, or something? Whatever happened to the days of moderating up Anonymous Coward posts..? ; P
Hi,
I use both Mandrake and Red Hat. And IMHO, urpmi is better than up2date. I've been using urpmi (or its GUI interface, MandrakeUpdate) for a while.
And URPMI just plain works.
Every day, I fire it up to check if there's something to be updated on my system. If there is, I upgrade no problem. If there are dependencies, you can opt what to do. And it has the same interface as the SoftwareManager. So it's the same thing installing, uninstalling or upgrading.
This is called consistence.
I've read that some poster tried to update the Kernel with this tool from the GUI. I can only say "you moron!". When there's some Kernel to be upgraded, some library to be upgraded, I take my time to read what is this alla bout. So, reading a little can save your butt. What is wrong with that ?
Also, when updating KDE make sure that you are not running KDE. Idem with Gnome.
Anyway, I would recommend to home users wanting to avoid rpm-hell to try Mandrake + URPMI / MandrakeUpdate.
Hopefuly, Red Hat will take URPMI and implement it on their distribution.
All the best,
opkool
(sorry for the extension).
When using apt there are three primary factors affecting the success of the opperation.
.deb, .rpm, or otherwise.
1) Apt & it's ability to direct traffic.
2) The quality of the packages being installed, be they
3) The quality of the "packages" files on the server you are retreiving packages from.
Apt will not work well if items 2 and 3 are poor. Garbage in == Garbage out. If high-quality packages are used, and the server they are on maintains accurate and up-to-date "packages" list files (where apt gets detailed info about the packages available for download) then apt will work very well. If you are still having dependancy problems with apt then it is likely that items 2 or 3 above are the root of the problem. If the food tastes bad you don't blame the plate.
-=-=-=-=- osjedi uses Debian GNU/Linux. -=-=-=-=-
Check it out, it creates an RPM (including dependencies) and installs it, from any source package. Really nice.
:-)
To find it type gg:checkinstall in your konqueror window
Moritz
No one thing makes one distribution better than another. You can't make your "favorite" rpm based distribution as good or better than Debian without making your distribution actually become Debian, shape and form.
If you really want to do yourself a favor, then when Woody is released, download a copy and install it. Sure the install requires a little more work than other popular installers, but once you get the OS running, system administration is a snap with apt-get and the standard apt-lines. Its time we all put these commercial distros down and use the one true Linux distro... the distro made by the people for the people.
Based on the available packages on my installation (an older Potato):
Number of How many
Packages Maintainers
1 94
2-10 256
11-20 70
21-30 33
31-... 30
Pipes rule.
"The great thing about multitasking is that several things can go wrong at once." -me
Look here, it is being implemented as we speak.
h ol d=2&commentsort=3&mode=thread&cid=2680676
http://slashdot.org/comments.pl?sid=24672&thres
Anyway thanks for the info. I bought Freebsd 4.4 last week and haven't installed it yet. I spent 2 hours on the net last night trying to figure out how cvs-up and pkg-add worked and whats the difference between pkg-add and apt-get. I believed you answered my question. Well off to my install cd's.
http://saveie6.com/
Mandrake's installer sux more than a six-liter turbo engine and you know it! Debian will never use such an inferior POS! Never!
What about dependency loops?
I'm afraid I don't know of any loops in Red Hat... but it would be possible to create them. Do you have any examples?
How do you make sure that at no point does bash, or libc disappear or stop working?
Because if I tried to uninstall bash or glibc (or install anything conflicting), RPM would notice that all sorts of dependencies get broken, and would refuse to continue without the --hose-my-system option.
i've used up2date to update the kernel on redhat 7.2 and it didnt give me any trouble. i've also had a bad expirence when updating the kernel in redhat 6.2. it screwed up symlinks everywhere and nothing would compile.
i agree with you though-it shouldnt be an option if it doesnt work. especially if it is known not to work.
shit happens. redhat works sometimes, so does mandrake and so does debian. debian can be frustrating. everyone says 'just use apt-get install crackwhore' and it will work. i've found debian works great if you stick with stable. whenever i've used testing or unstable i invariably break apt in some way. which requires alot more effort that people imply with quick statements like that made above.
a
-- john
By a curious coincidence I just spent most of my weekend installing gentoo. I like it--especially the Portage package management system--but I have two warnings for potential converts:
1) There is not much documentation. Unless you really know what you are doing you will find it hard going.
2) There aren't many packages so far. I hope this will change, but in the interim you should expect to install a lot of your favorite programs from tarballs.
Unfortunately the solution is not open-source/gnu/whatever your fav. term is, friendly. With RH, Soose, SnackWare, YD, or whomever, in control, how can a regly joe developer fix a packaging bug? A bug in the code, yes, post your patches, etc. But packaging is a meta-data thing that is mostly immune to the usual bug fixing process. It is the delivery of the code, not the code itself, so its 'above the law' in a sense that the code itself is not. Sure, I could take a distro and just fix the prereqs or other packaging stupidity, but:
I cannot install a fix to buggy/stupid package delivered to me on a CD. Once it ships, its a done deal. Which means getting packaging right the first time is even more important (though often undervalued and underappreciated). Electronic distros can be fixed more easily, but releasing a new copy of a package with the same version is bad juju, and how many folk wanna upgrade versions just to get a fixed package which they've already managed to get installed?
"... lets have a little data replication to keep the system working"
I agree with this. Disk space is no longer an issue. Memory cost is no longer an issue. To make things easier to install, let's in some cases not share libraries.
Linux would benefit enormously from easier install methods. My customers won't use Linux until then.
Bush's education improvements were
I even switched to slackware thats how strongly I feel about this.
Surprised that Red-Carpet doesn't support KDE?
Remember it was brought to you by those same wonderful people who started up Gnome.
The campaign to sabotage KDE is still going; it's just a bit more subtle than before...
No, I think I will stick with compiling packages myself. After all, I have had nightmares that your worst dreams could not touch of the 'dependency paradox till thine system doth need rebuilding' kind. Apt first of all needs a redundant roll back feature, and then the maintainers need to do a much better job of testing their debs. Another good feature, besides the roll back, would be a scaled dependancy check that will allow, easily, for incompletely installed packages to be 'counted' as installed if you know that you will indeed be installing all the requirements. Easy being the key here. The more time I waste on this is time I cannot develop.
perhaps there could even be an effort by package creators to deny the urge they seem to relentlessly hold that forces them to require the very latest dependent libs and such and can operate in the 'older' (as in 3 weeks old) libs' environment. Perhaps the open source community could use an overhaul on its method of design and architecture. It would be better served by a scalable lib adoption that is by nature backwards compatable. If I don't have, for whatever reason, the latest greatest 0.0002 seconds old glibc or such libs then it might at the worst just disable some 'advanced' features that are new to this release. After all, If I merely want to upgrade X to use my video card, then I should not have to upgrade 30+ interdependent and paradoxically linked other packages.
As someone considering moving to debian, this is the biggest sticking point for me.
One of the big selling points of progeny was a good installer (and commercial support).
Now that progeny is no longer making their own distribution, has their installer made it back into debian (i.e. will it be in woody)?
There is _NO_ fucking reason you can't install/upgrade using the tarball ./configure && gmake && gmake install under Red Hat
There are two problems with that.
Thus, you can never rely on a package system. And once it lets you down, as it inevitably will, you can no longer use the package system safely.
Compiling tarballs is the only way. It's ironic that you refer to it as masochistic, because it is the only way to work with Linux without ever getting frustrated. All the other ways lead to frustration. I use Slackware and source tarballs because I am not a masochist and I don't like having to fight my computer.
It can be run from cron (so root gets e-mail reports) and you can configure it to just download the updates (it does also update the updates so the older ones get deleted) or to install them automatically for you. It can compare the remote updates against those installd on your system or against a set or rpms you specify. It can even upgrade your kernel updating the LILO or GRUB configuration if you tell it to do so.
I'm using it to download and (for some of them) install all the Red Hat official updates for 6.2 and 7.2., also Ximian GNOME (w/o the Red Carpet bloat and using FTP or [S]HTTP so no proprietary server portion as in up2date is necessary), the unofficial HDE 2.2.x rpms maintained by Benjamin Reed at ftp://ftp.opennms.org/people/ben/, ..
It really shines when the repository maintainer does publish the dependency database (created by using nothing more than rpm and the autoupdate script itself) along the packages.
Give it a try, you will not regret.
The author is Gerald Teschl
The URL is:
http://www.mat.univie.ac.at/~gerald/ftp/autoupdate /index.html
-- Ramiro
Ok, that's it, rather take years to wibble through figuring out how to put Debian into a loopback device on a windows machine, I'll just install http://www.DragonLinux.org/ and install apt.
What a wonderful thought! Gee, I'm glad I've got a nailed up ISDN line...
Bob-
The Ludwig von Mises Institute. The reasoning individuals economics
Don't wait for some "installer" that other people say is easy, just install the system. If you've used any kind of *nix, you won't be weirded out by the install of Debian. At worst, you might choose to go with the defaults until you know more about your hardware.
You will be surprised how well those "defaults" work, I believe.
Bob-
The Ludwig von Mises Institute. The reasoning individuals economics
Since the linux people discussing on this forum are *BSD ignorant",
/var/db/pkg and includes several items of information
/var/db/pkg/zip-2.3
/usr/local
:
/usr/ports/distfiles]
/var/db/pkg database and all the files in /usr/local or /usr/X11R6]
/usr/ports/packages/All/foobar.tgz to that file with the latest version.
/usr/ports/category/foobar && make && make install && make clean
/usr/ports/category && make install clean
p orters-handbook/
/var/db/pkg database.
/var/db/pkg is
h andbook/ports-using.html
and the BSD people only say how great it is, and not WHAT it is.
I'll try to explain how Darwin & Free/Net/OpenBSD handle their packages/ports.
What are packages? [on a BSD system]
BSD machines have a database of installed packages
it resides in
for each package :
Let's take zip-2.3 for example.
--[ cut here ]--
>ls
+COMMENT +CONTENTS +DESC
>cat \+COMMENT
Create/update ZIP files compatible with pkzip
>cat \+DESC
Zip is a compression and file packaging utility. It is compatible with
PKZIP 2.04g (Phil Katz ZIP) for MSDOS systems. There is a companion to zip
called unzip (of course) which you can also install from the ports/package
system.
>cat +CONTENTS
@comment PKG_FORMAT_REVISION:1.1
@name zip-2.3
@cwd
@comment ORIGIN:archivers/zip
man/man1/zip.1.gz
@comment MD5:eb512a4327cef91f4c5cd971dca0e534
bin/zip
@comment MD5:02da2a2388309f488724a3350a9ce9ce
bin/zipcloak
@comment MD5:d18f0d9ddd9ddacc0b0d4063fd3def40
bin/zipnote
@comment MD5:50ccc4fb0e4a33f57ede001867ebcaad
bin/zipsplit
@comment MD5:3d6696890b4313fcf1d056fade63fcd7
@unexec if [ -f %D/info/dir ]; then if sed -e '1,/Menu:/d' %D/info/dir | grep -q '^[*] '; then true; else rm %D/info/dir; fi; fi
--[ cut here ]--
What is this?
The +CONTENTS file includes a listing of all the files that
this package installed (with MD5 c/s) and commands to execute
when removing it, like removing the directories it created.
It is known that linux software writers provide with rpms, but not with FreeBSD packages.
So where do FreeBSD packages come from?
FreeBSD packages come from the ports which come from contributors, bug reporters, developers,
ports is a collection of Makefiles and patches that gets updated with CVS and with 'send-pr'
a *BSD user can send his own BSDification of software to *bsd developers for them to cvs checkin.
In the core of the ports collection there is a system of makefiles that makes it possible
to write a simple very Makefile that will do all this
1. download the sources from known or unknown mirrors
2. extract [after checking MD5 with the source file, the sources reside in
3. patch for the specific *BSD [Darwin != OpenBSD]
4. configure [just run the configure script]
5. make [will use gnumake if the package requires it too]
6. install [add the package to the
7. package
the mentioned 7th step [package] will create a BSD package for the port, put it in
/usr/ports/packages/category/foobar-0.0.tgz
and will link the
This is what most users don't do, and what BSD mirror sites do.
The All/file.tgz makes it possible to install the latest version of the package from the ftp,
afaik this is very similar to apt-get.
On FreeBSD one would use
> pkg_add -f foobar
And will get the latest available version on the mirror,
(you can set the mirror to something closer to home if you need).
So, basicly, just typing
> cd
or even
> cd
Will build, and install - with all the little tweaks needed for it to run best on the BSD system.
[like all the bsd junkies have told you]
MOST IMPORTANT:
It will also install all needed dependencies that this app can't work without if they are not on
the system already.
For some basic understanding of how people make BSD ports and how to contribute
I suggest reading the porters handbook of FreeBSD which lays it out really nicely and easily.
It's shirt and simple - so take 5 minutes of your wasted time and read it.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/
The installed ports (which are now called packages) get into the
What is a package? [again]
It is just a precompiled port that someone else compiled for you.
There is a machine on the FreeBSD site that compiles newer ports all the time
the compiled versions get into the packages mirror, which is part of the BSD mirror.
And to summarize a few additional features :
- ports update with CVS [you always get the latest version]
- ports compile on freebsd without problems - no newbie compilation questions
- packages are the same as ports
- all bsd users contribute to ports via bug-reports ['send-pr']
you can see the "bug-reports" HERE
What tools are available for handling the database?
The basic ones that come with bsd are these :
pkg_add
pkg_deinstall
pkg_version
pkg_delete
pkg_info
Recently there have been a VERY powerfull addition to how ports are managed on BSD.
It's called 'portupgrade'.
This new portupgrade tool lets you keep track of dependencies better than what
the core package handlers and ports collection has.
The most noted extra ability that makes it so powerful,
is that it considers dependencies version specific.
Before this utility, if package A-0.1 needed package B-0.1
it installs it, because it's a dependency.
Then when package A-0.2 comes out and there is package B-0.3 available,
then when installing package A or making the port - it would
not install the dependency port B, because B-0.1 is already installed.
portsupgrades changes that, it will install a package and the latest
versions of all it's dependencies before it installs the package itself.
Second valuable thing that it will do is remove the package before it installs
a new version of it. In the past when you installed a higher version
of something - the files of the old package that no longer participate
were forgotten, and became junk - this is because the
rewritten with new package information, but the files were not removed.
With portsupgrade it doesn't happen, portupgrade prepares the new package
to be installed, then it removes the old version before installing the new.
Another valuable resource for FreeBSD porters is http://www.freshports.org/
It keeps track of new versions of ports added to the CVS port collection,
and lists it. So you know when your latest version of foobar is written as
a port (which usually takes just a day or two after it was released).
Maybe the linux developers will read the porters handbook that i've mentioned,
and be more comformative with the BSD community.
This is enough information to get you going.
More info can be read at :
http://www.freebsd.org/ports/
http://www.freebsd.org/doc/en_US.ISO8859-1/books/
#FreeBSD and #FreeBSDhelp on EFnet