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*
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...
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."
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.
SuSE with their YOU (Your Online Update)
YOU == YAST Online Update
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
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.
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.)
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
Well... that depends on your point of view. Granted, I think there should be a way for software to include its own dependencies, but that kind of goes against the system and is missing the point.
If you're installing from a distro's CD, then it should have all the dependencies right there, no problem.
If you're installing randomapp.tar.gz, then it's a bit more complicated. Sure, the tarball could include a copy of glibc, but why should it? My distro should include one that's up to date, and if it doesn't then perhaps you want to stick with the distro's method of adding libs so they can be easily removed later. For example, if I install a game that uses SDL, but that game isn't included on my distro CD, but the SDL libs it requires does, do I really want those libs to come from the download or from my distributer? I'll take the packaged SDL personally, just so it is easier to manage within the pre-exwhat you suggest is done on a lot of apps. For example, I just installed the Staroffice beta yesterday and all it required was a decent kernel and glibc. All the other libs were in there. You could throw all your requirements in to one huge package for download, it doesn't really jive with the modularity of the system, which makes for quicker downloads and less duplication of effort.
"I may not have morals, but I have standards."
I know that I will catch a lot of flack for this, but try to understand that it's just my experience. Anyways, I haven't been labelled a troll in a while, so I might as well burn some karma.
...but only if you can ignore the people who are associated with it!
The question you're asking could be "why do people use RPM?" -or- "Why do people use RedHat, Mandrake, or SuSE?" I'll try to briefly give my answer to both questions.
Why do people use RPM?
As far as I can tell, RedHat and RPM came first. I never heard of Debian until RedHat got to version 3.0.x, and I never heard of anyone actually using Debian until even later. I think that I'm not the only one, either. Regardless, RPM was a hell of a lot simpler to use back then (I could create a binary RPM package in just two or three minutes, using my favorite text editor). Debian's system was a mess! Whoever wrote dselect had no clue. apt and dpkg didn't exist. I couldn't understand why anyone in their right mind would bother to create packages for Debian. So, I got better and better at RPM packages and kept ignoring Debian, because nobody ever used it and the software sucked. Eventually, someone finally wrote a real package manager for Debian, and I have to say that I was impressed. I decided to install Debian after that. And that leads us to...
Why don't people just give up their RedHat, Mandrake, etc and use Debian?
Because the people who use Debian are political wackos and elitist assholes! Yes, yes, I can see the (-1, flamebait) moderation hitting me hard right about now, but try to understand this is just my experience from being on the Debian lists and talking to Debian people on Usenet. I can't stand them. Someone on the main Debian mailing list once called me a 'hacker' in a derogatory sense! Funk dat. Debian people suck, and I haven't met a single one that I'd like to be associated with. They remind me of a combination of the worst qualities in OS/2, Amiga, Macintosh, and FreeBSD users. 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. There is no chance of me using that distribution ever again. I refuse to be associated with people like that.
I'm sorry that this is flamebait, but I can't come up with a better, more tolerant way of putting it. Call it a personality clash, low tolerance for assholes, or me being immature... whatever you want... but I'll freely admit that Debian is an awesome Linux distribution.
I just want to use Linux. I don't want to join some stupid "Windoze SuX!!!!" club, I don't want to change my political party (I'm more of a green than anything else), I don't want to call my operating system GNU/Linux (wtf?) or Lignux or some crap like that, and I most definitely don't want to called names on the support mailing lists.
Maybe if someone archived the Debian mailing lists from 5-7 years ago, they'll see me getting flamed outrageously by Bruce Perens himself. It has always been my opinion that Perens, ESR, and most of the other people involved with Debian were blowhards, and this just reinforced my opinion.
Why do I use RedHat, Mandrake, SuSE, etc? Because they're quite good enough for the job (maybe not the best, but good enough), and the people who use them don't act like spoiled, egotistical 5 year olds.
Alright, let the moderation commence...
I wanted to know if you install something using
./configure
make
make install
Is there anyway to uninstall it?
This would be the worst of all possible worlds. Just ask on comp.os.minix ... since the underlying system isn't free, it has become fragmented and forked all to hell with the various free patches that often conflict with one another.
utter rubbish
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.
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
Yeah - trust me; this is the new kernel...
Hey!!! the parentheses are good for something
Actually, it seems that a lot of people have problems with unstable, at least from the comments on debianplanet.org.
A deep unwavering belief is a sure sign you're missing something...
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.
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.
You actually found it? Wow. Well, I'm impressed.
Check out the reply calling me a hacker. It's classic.
My complaint on this subject is about coders who play the "If it runs on my box, it's good enough to release" game.
... I suspect he probably developed GnomeMeeting under the as-yet-unreleased GNOME 2.0 rather than the current stable GNOME 1.4.
... if you are going to push your stuff out as the greatest thing since sliced bread, make sure it will build and run under a fully-'stable' version of kernel/libs/sysutils ... anything less marks you as an update snob and your project as less than useless ...
As a case in point, consider GnomeMeeting. I have an INTENSE professional interest in videoconferencing under Linux. GnomeMeeting shows considerable promise for fulfilling this need, but I can't get it to build under Debian woody. Despite the fact that I run apt-get upgrade at least once a week, the developer is apparently using some library more advanced than I have on my system
What's the point of all this? Developers
utter rubbish
#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
why not just move distributions over to dpkg/apt/DEB management like Debian, or FreeBSD-style ports
Riiiiigghht. And that will happen straight after Debian adopts the graphical Mandrake installer, which is completely superior to Debian's tired old offering. It's all free software, after all, isn't it?
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."
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
Yeah, I agree with you there. The problem is, at what point do you stop? Gnome is freakin' huge! Do you really want to download it all with your gnomemeeting tarball? Especially if it's for a system that already has what you need?
Granted, there are problems both ways, and I think the ability to have two packages, one with the libs and one with just dependencies that you have to fetch, would be a better solution.
But you're right, in the end the developer should be concious of what everyone else is running.
"I may not have morals, but I have standards."
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."
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."
Two old lighthousekeepers lived in, well, a lighthouse far away from pretty much everything. All they did was sitting around all day telling each other jokes. Since they had lived together in the lighthouse for many, many years, they alread knew all the jokes and didn't laugh much at them. Who likes old jokes, right? But they didn't have anything else to do so they stuck to telling the old jokes anyway. One day they came up with the idea of enumerating all the jokes. That way they spent less time telling jokes and more time saying "haha". (They were already pretty tired of the old jokes, remember.) So the days went by something like this.
Keeper1: 16!
Keeper2: Haha.
Keeper2: 4!
Keeper1: Haha.
Well, you get the idea. But one day something exciting happened:
Keeper1: 12!
Keeper2: Haha.
Keeper2: 14!
Keeper1: Haha.
Keeper1: 256!
And keeper2 fell off his chair and rolled around laughing his ass off, because he had never heard that one before.
Ok, now I'll go hide in the corner of combined off-topic and lame joke shame.
I'll say! If you can't love without any app, you've got some real issues to work through!
"I may not have morals, but I have standards."
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.
Regardless, since you're obviously not interested in giving accurate statements about the current state of the Debian projects, its software, or its developers and users, why don't I throw out a URL for those that may be interested. You can simply over look this:
assert(expired(knowledge));
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.
I know what you mean about some debian users. I mean I have seen some real assholes myself.
But another reason is ease of installation. I mean I know Red Hat and Suse are easy to install, easier then Windows 98SE. But Debian is hell to install, I mean even FreeBSD is easier to install then Debian.
I was able to install Debian because someone was willing to guide me over the install process. It took 3 nights and was done completely over IRC. So I can certainly tell you there are some really nice Debian users out there.
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
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.
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.
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?!
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.
Then you spout I just don't see why anyone would run Linux and not want to compile software, be on bleeding edge, and actually administer a UNIX system... I feel like I'm running Windows 95.
To which a "mean" guy answers Obviously, you never administered a high-availablilty multiuser machine... just your little hacker playtoy machine. Try explaining to 200-300 users that you'll be down for a few hours because you installed some new software, and broke the system.
If you expect anyone to be nice to you after saying: Unconfigurable software with horrid defaults, plain bad planning, changing industry standards without notice, etc. you need a reality check.
Then in 1997-06 someone has cc:ed the list a mail to you about a webpage where you give your "opinion" on Debian. Apparently it contained the same FUD you produced in January.
I didn't find any posts to you from Bruce Perens, but I hope he tore into you for being so rude and arrogant in your ignorance.
I see no reason for you to complain about any rudeness or flaming from Debian developers/users since you brought it to that level all by yourself.
Personally I moved (in 1996) from Slackware to Debian because Debian was more up to date. I was never inclined to whine to the Slackware developers about them not working harder to satisfy my "bleeding edge" needs though.
You can do this with linux.
.profile/.login to add any directory you want to the library path. You can have libraries out the wazoo in your home directory.
Simply edit your
I dunno how rpm does with it, but if you compile for yourself this is simple.
Those who can't do, teach. Those who can't teach either, do tech support.
Damn, that's cool. I may have to install RedHat some day just to try that.
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
So you started dishing a bunch of general complaints about the nature of Debian, and couldn't take it when someone disagreed with you, and didn't care to up the politeness level. Um, yeah, people on Debian lists complaining that Debian is doing everything wrong and they should do it my way don't tend to get much respect, just like everywhere else in the world.
1 28 1814&list=199
For reference, the message is
http://www.geocrawler.com/mail/msg.php3?msg_id=
*
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.
So I should leave my exploitable wu-ftp server up and running, because I don't want a fix that is new? How about openssh? The fixed release of that is pretty new. Should I still be running my Bind 8 server? How do I tell when it is old enough that I can fix the bugs?
Enigma
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.
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".
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
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.
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.
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.
Yes, the install turned me off of debian the first time I tried it. Then I figured out the easy way: just install the base system and get it running, then use apt for everything else. It's quick, simple, and you don't end up with any software you don't need.
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
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).
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
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.
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.
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/
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.
Wouldn't that then be the "Latest Version" which the parent said should never be used on mission critical servers?
Enigma
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
This can already be done without breaking any current infrastructure. It's a little harder than under Windows, to be sure, but that's because Windows was designed for one user per computer, whereas Linux/BSD/Unix were designed to be multiuser.
/usr/local named after the application. Install the application and any libraries under it. Create a script named after the application that appends to the path variables then executes the program. Now symlink that script to ~/bin or /usr/local/bin, make it a desktop icon, and add it to your root menu.
Here's what you do. Create a directory under ~ or
This is still too much work for the average user, but it should be a piece of cake to write a generic installer that does this.
A Government Is a Body of People, Usually Notably Ungoverned
Yeah, that bit of his post puzzled me as well. Is the guy trying to say that, as of a few years ago...
That second point is the pertinent one, for me. Many people have complained about the dselect UI over the years, but AFAIK, until a few years ago there was no way to do the same thing on any RPM-based distro. (Rather a strong statement, so I'm probably wrong, which goes to show that I don't use RPM-based distros.) From what I understand, back in the Red Hat 3.0 days, the only way to install and remove RPMs from your system was one at a time from the command line. dselect not only presents a menu of all packages, lets you browse package descriptions (and other maintenance fields), search for keywords, sort out all your dependency issues before starting an install run, etc. And the auto ftp download bit has been around for many many years. In short, most of the features for which APT is seen as so sexy these days -- were in dselect four years ago.
I guess rpmfind.net was considered a valid workaround for this fundamental tool lack. I never tried it so I can't say whether rpmfind or dselect had the more- or less-usable interface. (I've always found dselect quite usable, if quirky and unintuitive at first.)
Complaining about the poor UI of dselect when all you have is command-line RPM is rather like complaining about the poor UI of someone's web browser when your platform of choice only has a command-line FTP client.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
Moderation Totals: Flamebait=1, Interesting=1, Total=2.
Honest discussion that says anything negative about linux isnt flamebait. I use linux, my point of view is a valid one.
holy shit...
that was just about the funniest thing i've read in my life. and i just watched a half hour of rodeo on espn2 after drinking most of a bottle of wine.
i hereby symbolically transfer the +2 karma i recieved to you.
A: None. The Universe spins the bulb, and the Zen master merely stays out of the way.
I agree with this completely. It wouldn't be too difficult to throw a ports.tgz onto the install CDs. I really liked the idea of BSD's ports when I briefly tried FreeBSD. (Unfortunately, they didn't seem to always work as advertised, but that's a gripe for another day.) One of Slackware's stated goals is to be as Unix-like (not "Linux-like") as possible and since BSD is the de-facto Unix these days, I don't see how ports could do any harm.
If someone's actually working on something like this, I would be one of the first to step up and volunteer to help out.
OK, I'm declaring myself the official maintainer for all the RPM's that install into /usr/bin in Red Hat's distribution.
Tell everyone over there at Red Hat to expect something from me next week, OK?
Do you see my point?
If tits were wings it'd be flying around.
The fact that there are users with problems (and many of them) implies that there are problems. Not that unstable is broken or sucks or whatever, but it has caused issues for some people. Even if, as you say, twice as many people use it without problems, don't you think a 33% failure rate if aweful high?
A deep unwavering belief is a sure sign you're missing something...