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')))
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*
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...
Personally, I dont hear too many new comments on /. anymore. I think that instead of writing everything out, we should recycle electrons and just use links to what someone else already said
That sounds a lot like an old Bill Gates legend, where he was tired of how circular arguments about technological religion would get. He joked that he needed a more terse way of talking to avoid the lengthy redundancies. "If I said 13, for example, that would mean 'that's the stupidest thing I ever heard,' and you could reply with 27 for 'maybe you should find somebody else to reinvent the wheel, then.'"
[
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.)
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."
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.
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.
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.
Debian/unstable is where new packages go. Here, packages are often built right from CVS. Yes, if you track Debian/unstable, you might get burnt every now and then from bugs. But on the whole, it's very good; everything is up to date, and it's about as stable and bug-free as a Red Hat
Debian/stable is almost totally static. The only reasons a package in Debian/stable is updated is for security reasons. Even then, usually, the fix will be backported to the version of the app that's in Debian/stable. For instance, if a long-present security bug is fixed in BIND 9.2.0, but Debian/stable asdlfkjasdglakjsdf, then the fix will be backported to that version; the package won't be upgraded right to 9.2.0. Why do this? "Stable" doesn't just mean apps that don't crash. It also means a common platform. Debian/stable will change only very, very rarely. This makes it an ideal target for sysadmins who wish to use trusted software, and for developers who want to target the lowest common denominator.
Yes, all three Debian trees use apt-get; in fact, moving from Debian/stable to Debian/testing is a matter of two or three commands, usually(ditto for Debian/stable -> Debian/unstable, or Debian/testing -> Debian/unstable). Almost all Debian mirrors have all packages from all trees in all supported architectures.
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
I wanted to know if you install something using
./configure
make
make install
Is there anyway to uninstall it?
Add to your list of communities with offensive users LISP and some parts of Java. I can't stand to read Java books that denounce other programmers and other technolgies, and too many of the LISP books I have read do the same.
Why can't they let the merits speak for themselves? Bashing others just turns users away - users like me who don't care for the politics.
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.
I'm a Debian user, and I think that you're generalizing way too much. People love Debian because it's the best at the things that they care about, and they have the capability to contribute to it.
As a Red Hat user, you don't get to contribute unless you work for Red Hat. Since you got flamed hard on the Debian list, you must have posted there. If you posted there, then you must have wanted to contribute.
Now, is using Red Hat scratching that particular itch? No? Then why haven't you started your own distribution to scratch that itch?
On the other hand, perhaps you don't want to contribute to a distribution. Why then in that case would you care about the Debian list? I use Debian and don't post to the list because I'm not a Debian developer.
To sum things up bluntly: don't cut yourself off from a distribution that is top notch just because you think that the developers (many of whom are not the same people who treated you badly) are jerks. You can use the distribution without ever talking to them.
If tits were wings it'd be flying around.
#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 :-)
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
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.
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.
Have you ever actually used RPM? It allows you to specify prerequisites with their versions in more or less the same way as dpkg. Certainly a lot more than just the version of shared libraries.
It's true that a lot of RPM builders do not bother to include this information. But that's not the fault of the format itself. A lot of the claimed advantages of .deb over .rpm are really just because the Debian people are more conscientous about packaging and anal (in a good way) about getting the dependencies correct. Ditching RPM is not the answer, better packaging quality is.
-- Ed Avis ed@membled.com
Whether something is a real server or not is not at all about the hardware it runs on, it's about what you use it for. And up to 2.4.16 you really don't want to run a 2.4 kernel on a server. Maybe you haven't had any problems with 2.4, but most people have. It would be much wiser to stick with one of the latest 2.2-kernels for a while until 2.4 has proven itself.
0x or or snor perron?!
The utility of the 2.4 series kernel in production is completely dependent on what your server's functions are. For example, my employer has a specialised audio/video streaming daemon which suffered from (read: design problems) network subsystem performance problems in 2.2. These problems could be fixed with some kernel source modification and recompilation, but that degree of modification should not have been necessary (based on WHAT needed to be changed in the kernel). In 2.4, 90% of the things needing modification can now be set via /proc or sysctl. The other 10% were design limitations in the 2.2 series kernels which have been addressed and resolved (at least, to our application's satisfaction).
On the other hand, I'm still running 2.2 for our SQL server. After 2.4.16 and later have been tested by some other bleeding-edge people with database servers, I'll move it up. The VM problems and changes in the kernel seriously scared me away from making an early upgrade to 2.4.
It's all relevant to application.
.... um, i lost you after "0110100001101001".
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".
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.
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.
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).
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.
:) for those of you not browing at -1...
that was bizarre and hilarious
A: None. The Universe spins the bulb, and the Zen master merely stays out of the way.
I believe that RPM packages always have md5 checksums on all the files, whereas .deb packages, by default, do not.
That's probably what you heard.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README