Slashdot Mirror
An RPM Port Of APT
A reader writes: "This editorial has been just published on freshmeat: 'After full integration of the RPM [?] patches into APT [?] , it will have the potential to become the standard package management frontend for Linux, shortening the gap between distributions and reducing incompatibility across distributions for at least one important system administration tool. (...) The temporarily-forked version of APT is already fully functional and actually works. Conectiva Linux 6.0 -- the first
RPM-based distribution to support APT -- currently ships with it, and has some repositories that are available for
use with APT.' It can be downloaded here."
I'm tired of my newly converted Debian friend (ex-RedHatter) mocking me when I have to update an rpm, and end up spending hours on rpmfind.
This should help keep a bunch of distros even closer... which should be the aim of all of the distributions, while keeping their various specific bonuses (such as Corel being businessish, etc)
______
everyone was born right-handed, only the greatest overcome it.
______
everyone was born right-handed, only the greatest overcome it.
http://leftorium.net
So do I. Don't know what's so bad about it. And here's what I do with that huge package list, if I install a fresh Debian system (still slink).
- Start dselect
- Mark everything as purged
- Search for the tools I know I will need (e.g. bash, vim, perl, gcc, xserver-common, netscape, gimp,
...)
- dselect will show me dependent package screen and I just hit Enter
- Install the distro. If anything is missing (usually not much), go back to dselect
This works especially well, if you do not have broadband internet connectivity and are charged by the minute. dselect is your friend for CD based installation.Free Manning, jail Obama.
Lol!
Timecop?
Silly mofo. I'm gonna beatchyo ass.
--
Slackware DOES have the easiest install. If you want to resize your windows partition, make sure you defragment, then just use fips. Boot the bootdisk, run cfdisk, make your partitions. That's the hardest part. After that, run setup, and you get a nice menu-based install. Set up your swap, choose your packages, and go. Or you could just do a full install of everything. Takes about 5 minutes to install. After all packages are installed, it asks you if you want to configure stuff, like network settings, etc. Its all menu based, using the "dialog" program. It even gives you a wide variety of default window managers to choose from.
About the hardest part after this is setting up X. And no, you don't have to edit your XF86Config file by hand.
Sure, if you have never used Linux before, it will take you a few hours to LEARN to use Slackware. But after that, everything is pretty simple. You don't have to edit everything by hand. Slack has some configuration tools for the most common things, like setting up a ppp connection to your isp; use pppsetup. Yes, down the line, you will need to edit SOME configuration files by hand, but it's really not that bad. Most of the configuration files are nicely commented, and it doesn't hurt to read a man page every once in a while.
Slackware also has a new update tool called autoslack. It's not considered release material yet, and is unsupported, but it's getting there.
Bottom line is, if you like to learn, use slack; If you like simplicity, use slack; If you like to know what's going on in your system, use slack. If you like having configuration files that say DO NOT EDIT, then use redhat.
Try using slackware exclusively for 30 days. You won't want to go back to your old distro.
Ok, I'll admit, I've never actually used another distribution on my own machine. I was gonna try redhat once, but I never could get it to install.
Overall, though, the dependency problem is minor, but broken packages DO sneak into unstable and stable (!!!!!) every now and then.
hey, you should look into the berlin consortium. I am currently thinking of programming some stuff for them, it looks like it has the potential to at least unify X with the many window managers, and make it a whole lot faster. I think we should work towards a more unified linux, choice is good, but when you are choosing between many incompatible platforms that all have benefits and weaknesses, it makes no sense. I like the berlin consortiums ideas alot (no more X!!!), if only we saw this kind of thing in other areas as well.
Shit adds up at the bottom...
(nt)
I knew a guy who call himself Mr. I-Am-Elite-and-Edit-Everything-By-Hand-in-Linux.. This kind of people really have trait. I should've challenged him to write assembly code instead. Being an 31337 == being a time waster. I think if he wants to edit config for his life, he'd better go back to where he belongs editing WinNT registry.
. 1/patches/
/etc/hosts.equiv that contains "localhost" line with rlogin service turned on by default (this was in my friend's Slackware 7.0 system). Okay, this is just by default and can be prevented, but what if the user does not know Linux at all and his machine got hacked?
Another thing is, security. For example, take a look at
ftp://ftp.slackware.com/pub/slackware/slackware-7
Only 1 patch? Come on! glibc local exploit, netscape java problem, lpr, ypbind, pine, etc. It hasn't been updated for hundred years, I guess.
This site (slackware.com) even uses FreeBSD instead of Slackware Linux. Identity crisis, anyone?
Linuxmafia.org claims that Slackware is more secure than Redhat. The truth is, Redhat is more consistent when updating its security, and Redhat is being honest, even though 7.0 was still under development.
Debian also pretty consistent when updating its security problem.
Slackware does a false advertising in Dr. Dobb's Journal saying that it has the easiest installation. Does it have a partitioning tool that can resize Windows and Linux partition so that you don't have to waste your money for Partition Magic.
I'm not trying to make Slackware's name bad here, it's just that I'm upset because my money is wasted for a piece of shit junk that can't even detect my hardware like Redhat/Caldera/Mandrake/SuSE. Moreover, people who use it claims that it's so secure, but its security is so crappy that by the default install it allows people to remotely break into the system because there is
My point is, both GUI and ncurses config tool is good, hardware detection is good. I just can't seem to understand 31337 people who waste a lot of time for editing by hand.
-- Microsoft, Inc. http://www.microsoft.com
The annoying "dselect" dependency handling will make you howl in pain. For example, it will "suggest" unneeded bullshit when you select a package. But the "suggestion" is more like a hammer over the head and you have to go and manually remove the additional cruft from its installation list. And that is not all. Many of the so called dependencies are not even real dependencies. For example, you might select a simple text mode package, but Debian will force you to install the X Window System front end for the package and all the X libs needed for that front end. But all you wanted was the simple text mode stuff. Tough luck, you have to manually f*ck around to remove all the unwanted BS. Debian is not so hot as its advocates claim. I base my opinion on several years of experience and not some starry eyed dreaming.
I (a while back, admittedly) posted an article that gets involved with the implications of a unified packaging format/specification. Since that discussion is rather dead, and this one is alive and kicking, I'll repost it here for your enjoyment ;-)
(Special note: I'm using Debian now, and kernel 2.4 works fine. Before you flame me, check my (edibiase's) replies to concerns brought up on K5!)
I'm about to scream. This is about the third time this has happened: I've gotten sick of Linux. I know what follows. I'll "try" Windows 2000, decide that I hate it even more than Linux, and move on to BeOS, FreeBSD, OpenBSD, Darwin, NetBSD, and then, to top it all off, QNX. At the end of that OS run, I'd think to myself, "Hmm. It appears that I do like Linux the best of all the operating systems I've tried," and I'll go back to Red Hat. But, after a while, I'll think to myself, "Red Hat sucks! It's too unstable, too bleeding-edge, and things don't always work the way they're supposed to. I need something that will work right all the time, like Debian. Debian all the way! One-hundred-percent free software, baby!" So I'll enjoy Debian for a while. Then, "Debian sucks! It's too out of date! Nobody releases DEB files for packaging, anyway! I won't be able to use Linux 2.4.x with Debian until the Sun dies, and that's optimistic!" Perhaps after this I'll move on to SuSE, and then to Slackware, and eventually I'll end up at Caldera. Once I get there, I'll be thinking, "Well, Windows 'Whistler' looks pretty neat. I'll give it a shot." In truth, though, I love Linux, but find it incredibly hard to use. I'll admit it, I'm rather a perfectionist in this regard.
Can we develop a more usable Linux?
To answer these questions, let me tell you a little bit about myself. I'm sixteen years old, and have been using Linux for a little while now; I'd estimate about four or five years. I want to go in to computer science when I "grow up." My real interests are in AI and user interface design, though.
My UI interest should come as no surprise, though, because I spend so much time looking at every single interface known to man in my quest for the optimal system. GNOME, KDE, Window Maker, Enlightenment, bash, DOS, Windows 3.11, Windows 95, Windows NT, Windows 2000, BeOS. Those are just the ones I can remember off the top of my head; I don't know how many others I can't even remember!
think I've come to the conclusion that I like Linux. It's fast. It's free. It's stable. It lets me mess around with programming, administration, and web development stuff, and it's starting to support all of my hardware (Quake III, the Matrox G400 MAX AGP, and XFree86 4.0.1 make a sweet combination). So what's the problem? I've identified several, and possibly you can add some more.
First off, there is nowhere near a useful level of consistency among distributions. Red Hat puts things in different places than Mandrake and SuSE, and doesn't even use the same package management system as Debian, Storm Linux, and Corel Linux. That's not to mention Slackware, or the other (millions?) of distributions that are around.
Not only is there no level of consistency in where distributions put things, but they use different package management programs, and there's no easy way to convert between them! Sure, there are tools like alien, but how much use are they when packages converted from one format to the other will probably only stick things in the wrong places and not interface with any kind of dependency system? The obvious problem is that I, J. Random Software Developer/Company, can't just release the J. Random Development Environment "for Linux." I have the joy of making a version for "Debian GNU/Linux," "Red Hat Linux 5.x," "Red Hat Linux 6.x," "Red Hat Linux 7.x," "Corel Linux," "Storm Linux," and "Slackware Linux." Yeah, I'm really going to want to create seven packages and manage them all. It's easier just to do it for Windows, or, as some companies have been doing of late, to release it for a particular Linux distribution only, and pretty much saying that any other platform is unsupported.
If we can get the consistency problem licked, it shouldn't be much of a jump to move to a unified packaging system, or at flock of compatable ones. Can't we come up with some kind of unified Linux packaging standard, with rules for creating, installing, and configuring packages, and work from there?
My last major point is that all the GUIs I've seen for Linux I'd classify in the "not very useful for Evan" category. I'm not saying that KDE, GNOME, and all the other Graphical User Interfaces out there for Linux are horrible (they're not), but rather that they're not what I feel comfortable using, and they're not something I feel many others would feel comfortable using. Neither GNOME nor KDE give me any real configurability as far as how I want my data to be organized, and they don't seem to have been designed to follow any sort of goal as far as user interface goes. I don't want to give the impression that I'm an expert on this, because I do not follow development of these projects at the mailing-list level, but this is what I know as an end user: it is really, really hard to justify using "mature" Free Software products like GNOME or KDE when they do not provide an intuitively designed interface nor a consistent way of working with the machine. Here's an example: I use GNOME most of the time, and it really irks me that things are so haphazard in it. Using a GUI should be easy, fast, and intuitive. We're moving toward fast (and, in many cases, are already there), but what about easy and intuitive? Let's cause a paradigm shift here: interfaces by, for, and of the users, as opposed to by, for, and of the whimsies of the arbitrary developer. Can we make an interface that nobody's ever seen before; an interface that will make Linux stand out more than it already does as a shining example of an excellent operating system?
Those are my ideas for a good Linux system. In a nutshell: consistency, good package management, and amazingly good GUIs.
But, you may say, this argues for the end of distributions! What good is a Mandrake to a Red Hat if I can just take the Mandrake packages and install them on Red Hat? To this, I say that perhaps distributions will have to do more to stand out. How is Red Hat presented? What does it include out of the box?
I know that the driving force behind any kind of evolution, be it biological or technical, is diversity. But how can we continue to justify diversification to the extent of exclusion? I don't think we can any longer. Yeah, you can go and hack your own system from the source, and only install the source. That's your choice. But let's agree that there are certain things that simply need to be standardized. I'm sick and tired of fighting Linux to get it to do what I want it to do, and I'm sure that many of you agree.
So, what do you make of my little rant? Is it too late for Linux? How much standardization is really necessary? I want to see this turn into something amazingly productive; I believe that the open source/free software concept, when harnessed properly, is the most powerful software development force yet known. Can we harness it to do something about this problem? Do we need to start a SourceForge project? Work with the Linux Standards Base and the distributions to try and standardize the important things? What are those important things? Do we need to standardize interfaces (I don't think so)? What about creating a package management format that works better than RPM and dpkg, and that will let software developers release one package for use with everyone? I look forward to hearing what people think, because we truly have the opportunity here to release Linux from something that, in my opinion, has been holding it back.
Yeah, it's a bit long, but it generated some good discussion on Kuro5hin, so I figured it might generate a similar level of discussion here.
Bough of you, please check out LFS... you may find it very interesting for just this reason;
http://www.linuxfromscratch.org
PS, This is like roll-your-own, using SysVinit (aka RH rc script), small and clean like Slackware, very good combination.
Based on the book I bought, RPM spec files seem to be overly complex. But then, all I really want to do is say what the package name and version is, and that's it.
now we need to go OSS in diesel cars
If there are "many" brazilians who don't like this, it certainly isn't the majority of them. And where the heck do you saw conectiva staff saying they invented apt? This is nonsense.
Conectiva is GREAT. Frankly, I like it better than redhat. They are innovative and give back much to our community (they pay full-time hackers like Rik Van Riel and Alfredo Kojima, for example). And they also license everything they program with the GPL.
Conectiva is one reason why I am proud to be brazilian. Instead of imagining they are traitors of the movement, you should also be contributing, not making up rumors.
Patola (Cláudio Sampaio) - Solvo IT
IBM CATE
SAIR GNU/Linux Certified
Patola (Claudio Sampaio)
Unix System Administrator
Then don't use a fancy packaging system, but a simple one. Indeed all this fancy stuff is a waste since it'll break sooner or later anyway.
Simple no-nonsense packaging systems such as those from Slackware of *BSD.
If a package installer checked what was actually installed, instead of what a database claims is installed, then I would be more interested in it.
now we need to go OSS in diesel cars
The current hearsay is that Exodus made a typo in a router config.
It's possible to create a deb package for most apps with about 30 seconds of extra effort (dump standard files into top of source tree, edit to change version name and add any vital dependencies, type fakeroot dpkg-buildpackage and wait). You'll end up with a package that can be dumped into a local apt archive and distributed site wide. I prefer this to compiling stuff by hand and installing because it becomes a real pain to keep track of which versions are installed on which systems I look after. Adding local patches is even easier - apt-get source packagename, apply patches, add an extra entry to the changelog and change the version number so that mine won't be overwritten. Rebuild and I now have a package that's identical to the one produced for my distribution except with the changes that I desire.
Sure, this isn't exactly what you want. A system that could do this sort of thing automatically (maybe some sort of wrapper around install(1)) would make life easier still, but with the current situation the time a decent packaging system saves me easily outweighs the extra time taken to play by the packaging system's rules when installing stuff.
Same with me for 2.2, I didn't even touch dselect after the install and then the very next day I just dist-upgraded to woody and since then I think I've only gone into dselect once to maybe try to learn how to use the damn thing but after doing a few things I just quit because I thought I would hose the system with the stuff I did. Since then I've never tried it again because I don't need to thanks to apt.
*shrug*
I'm not sure where my first reply here went to. It didn't show up. If it does later, sorry.
My interest is not in the space vs. speed tradeoff. I'm not particularly trying to save database space. Instead, I'm trying to save hassle and time administering the system. Packaging systems promised this, but eventually do not deliver. Your suggestion is also an increase in my time. I would much prefer to see a system audit tool that looks at what is actually installed. You could correct a database with such a tool.
now we need to go OSS in diesel cars
So you've just described apt-get, but you have to compile everything. How easy is it to remove packages? I allways hear people tooting the ports tree as being something revelutionary, yet I still haven't heard anything unique about it. Your claim that Debian copied BSD is kind of unjustified. At most you can say they were motivated by it. Did apache copy ncsa? At least with apt, you can simply apt-get update. How easy is it to update the ports tree?
So its "tastefull" to use a BSD kernel in Debian? The kernel was "patched" into their userspace? How often should a system administrator have to update her kernel? If it's some where like once a day then I would understand why CVS is more convenient...
Please get of your holy stool...
Don't get me wrong, I like Debian for a lot of reasons, but apt is the absolute killer app that keeps me on Debian. I now find myself wondering, if RedHat adopts apt, what would happen to Debian. Would it be enough for me to switch back? I guess the question is how many RedHat users switched to Debian solely because of apt.
One possibility is, of course, that RedHat wouldn't adopt apt because it would cut into their financial stream from RedHat Updates.
Anyone have any opinions on this?
And please don't mod this as a troll. I'm not trying to start a distro war. I'm really only looking for intelligent discourse about how this might change the landscape, especially w.r.t Debian.
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
Have you tried Debian? Of all Linux distributions it's the most consistant, and it's the only one I know of where failing to follow existing convention is considered a serious bug unless there's a damn good reason for it. See the Debian policy manual for more information.
If you're looking for an easier-to-use debian, I'd recommend Storm.
What is this "either/or" shit? There are times to use apt or rpm, and their are times to compile things from scratch. At this point, I use apt 70% of the time, and tarballs the rest. On RPM boxes, I probably use rpm only 40% of the time, and tarballs the rest, because it's nowhere near as easy to use rpms as it is to use apt. I use dselect only when I absolutely have to, like during an install.
Each method has some things to recommend it, and there isn't a reason to use one or the other exclusively, as far as I am concerned.
It's more standards in the way we do things. Installing RPMs can be a pain sometimes but with people taking steps like this I think it's great. APT is going to make it easier for people to install and update now there distributions of Linux now. Isn't that great!? I would like to go to an site and just download something install it without picking what distributions and version I'm using or use an update program to get the next version of GIMP. If APT is something I see in the next Mandrake,Redhat or any distro I'll be happy, because long as someone is taking that step. If you ask me, I'm up for a change... I don't care if RedHat drop RPMs and started using DEBs with APT. Long as it help get Linux on more Desktop and help get more apps.
From Zero to Hero... Starbuck Zero
I know that linux distros are not supposed to be competition to each other, but in my experience apt is the best part about debian and it being standardized will severely hurt its market share
Now, for your claim it won't work, it's unjustified. Let them at least give it a try.
Dependencies problem!? Isn't that EXACTLY was apt is supposed to do? Solve those problems? Your arguments are not making sense to me.
And last, the dependencies have to be well-thought from the vendor point of view. If Conectiva proposed using apt in their next release, they have to make it work on their repositories. If you wish to add apt to another distribution (say, you want to use original apt on Slackware or even Corel) or you want to use another source of packages, it's your own risk. They can't possibly be considered responsible for someone else's packages. Nor can Debian be considered responsible for use of apt on Slackware or Corel (that uses .debs) or use of third party packages.
Or can they?
Am I the only one who still uses tar to install software?
...or you'd have Slackware's packages.
:-P
No annoying dependancy check there, just install the package and look for the errors you get when you try to use it!
Slackware is the uber-l33t version of Linux for Real Men.
Too bad the Realtek 8139 driver doesn't work even in 2.4.*, or I wouldn't have had to switch to FreeBSD.
Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei
Too bad. Then why the comment about 'getting off your holy stool', if you admit the BSD design is cleaner, and you didn't give BSD a chance to shine?
I made the remark because the guy was zealous. Just look at the title of his message.
Do they have kernel modules in any of the *BSDs? Its really a usefull feature for higher level kernel programing. Its pretty nice to be able to dynamically change what hardware the kernel supports as well.
Maybe it will work, maybe not. Maybe this will lead to one linux. If there's one apt, there's one Debian. Thus perhaps this would make Red Hat people point their sources.list to SuSE's repository as well, or Mandrake's.
:-)
Speaking of mandrake, keep in mind not all distros offer an online download of individual packages. So this may also filter out these pseudo-free distributions.
But this is a giant leap forward for RPM-based distributions everywhere; I'm still not using them though
# debian/rules
a good os vs linux
Thats the kinda FUD that steers me away.
It's not exactly like what Redhat does, and there aren't as many of these tasks as might be appropriate -- but the idea will scale better than Redhat's, I think, because you can easily add and combine different sets of programs and do so at different levels of granularity. And it's easy, since apt can deal with all the interdependance so the task- packages can be very simple.
-As other people mentioned, it is not just downloading a package and installing it, it is also about having high quality packages with high quality dependency checking. Mandrake/RedHat routinely do not have an rpm I want, and after only a short time of installing packages that I get on rpmfind, my dependencies are so screwed up I need to do a clean install (as in reformat my system partition) to get things working.
-You only have access to the updates on your current version. For example, if you have Mandrake 6.1 and Mandrake 6.2 comes out with a new version of emacs, then the automatic update tool doesn't pick it up. (This is what happened to me, and I haven't stuck with Mandrake long enough to see if it changed.)
The biggest problem with the rpm distros as opposed to Debian, is the update process is not a "smooth". With Debian, you can update periodically and end up with updating just one package to get the "official next version". I would LOVE to have that smoothness with RedHat or Mandrake, especially for the security fixes.
With the commercial distros, they want to get you to either buy the next version or subscribe. I have no problem with paying for a subscription that is reasonably priced for my work machine (where RedHat is the most useful distro), but their subscription service is outrageously priced for businesses who just want to click a button and download the latest packages. I like a lot of RedHat's plans and directions, but when I look at their quality and price, I don't think they really have it together.
Demo here :)
The only thing thats missing is "dist -update", as that's how they make their money
--
Full plate and packing steel! -Minsc
Full plate and packing steel! -Minsc
Why is it great to compile everything if you are on something other than x86? From what I've heard, some of the slower boxes (m68k, for example) are real pains to compile large programs on. You also don't have any assurance that the code even compiles on your platform. With Debian compiling for Alpha, ARM, Sparc, M68K and PowerPC, there's little difference between i386 and any other platform.
As for having the source on hand ~/Program_Source comes to over 500 MB on my system, and is usually one of the first places to look for needed space. I'm glad I don't have to carry anywhere near the source for every program on my system. I can apt-get source (or buy a CD) if I need the code, and delete it when I get done.
You should try softupdates. It makes an enormous difference (since without it, FreeBSD's conservative default is write all metadata synchronously, whereas for Linux it is asynchronously). Being a benchmark fanatic, I benchmarked Linux and FreeBSD filesystems on all kinds of harddisks for years. FreeBSD's FFS has nevre been surpassed by any other filesystem I've seen on PC's; this includes all Linux filesystems such as ReiserFS.
I'm talking about all kinds of FS performance:
I am not a FreeBSD bigot but when it comes to filesystem reliability/performance there is no better option at all than FreeBSD. Which is why the worlds largest sites that are mainly dependant on filesystem performance, such as ftp.cdrom.com and other "download" sites run FreeBSD.
Sorry, I really wanted to install Debian, but after 3 hours of trying to configure X by hand I returned to Mandrake. I later even tried to install Corel Linux and then apt-get the rest of Debian, but it only created inconsistencies and dependency problems (besides I only have access to very limited bandwith -modem-).
I, too, am a Mandrake user, but as soon as exams finish, I'm planning on switching over to Debian. I'm sick of RPMs, inconsistant packaging, and that damn Mandrake Update that, for the last couple of months, has only been showing me packages that I've already installed!
The thought of having to set up my own XF86Config doesn't concern me in the least, since I've already done it in Mandrake. I didn't like the job that the automated tool did (some ugly flicker), and I wanted to change the default keyboard settings, so I read the man page. It wasn't so scary.
Of course, I realize that not everyone wants to do that. It's been mentioned already in other threads, but have you considered trying Storm Linux? It's a much more faithful child of Debian than Corel, and I have yet to read one bad word about it. And it has more of the pointy-clicky tools you're looking for.
Hah.
Hows that for a low UID?
Stating on Slashdot that I like cheese since 1997.
Heh, I know you're just trolling, so its probably on purpose, but I couldn't help but get a chuckle from seeing the phrase, "rage with an identidy you coward," from someone going by the name "barneyfoo." Thanks for the chuckle; troll on, as you keep the bites chomping well.
Deo
Terradot.org: Growing Awareness
Good for you.
:-P
Your post helps show why we need moderation.
Stating on Slashdot that I like cheese since 1997.
So what's your suggestion then? How do you propose that a package installer determine what was "actually installed", without resorting to the use of magic?
Yes you are right. The only thing that comes close to Slackware for being totally 31337 is Debian of course. This was proven to me earlier in the week when I installed Mandrake 7.2 on a new system equipped with a Mylex AcceleRAID 170 card in 18 minutes.
Fear not!! I was in no danger of being sucked into the lameness of Mandrake. Our Debian surfin' sysadmin came along, wiped Mandrake, and then spent the rest of the week being 31337 with the Debian installer that didn't work and didn't recognise the Mylex card.
He got it in the end...after spending about 3 days reading DejaNews and formatting specialised boot floppies with specialised kernels on them. Damn it was an 31337 experience!!! I felt like a fool for using Mandrake all this time that completed the whole installation in 18 minutes. Never, never again!!!!!
31337 Debian and Slackware all the way!!!!
"Inevitably, the database will get out of sync .deb or .rpm file is available right then, or..."
the moment you have to compile something from source because no
I agree with this. and it is THE PROBLEM and it would make everybodies life easier if it were "solved".
I disagree with your reaction to it though. Why not make the goal that the database CAN NOT get out of sync?
The implication is that when do need to compile something from sources (or do a patch) - that you create a package to add it to your system. Until the tools are made to make this very trivial it is not practical. but it makes sense as the goal. It also gets to a position where when you run something - anything on your system - it is ready to be put on somebody else's system. Lets take it all the way - I mean write a perl script or a bash script and rather than "chmod u+x script" - tell the system "apt package and install script" - or whatever. sounds crazy? perhaps, but think about it a little longer.
However trying to detect dependencies through what is installed is worse than "not easy". So I want to go the other way!
The solution to this, of course, is that you learn how to use the packaging system. So instead of just installing the thing that you want to install, you build a package for it and install the package. In the worst case scenario, you could build an empty package that only meets the dependancies that you are trying to meet.
I see the database as a tradeoff in the space vs speed deal. You can save space by not having a database, but determining if dependancies are met w/out a database will slow down your package management.
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
I never used dselect beyond seeing if it had changed. I just installed the base system, and apted everything else I needed.
treke
Everyone says this about RPMs, but it doesn't have to be this way. look at the urpmi set of tools that are included with Mandrake. urpmi automatically takes care of RPM dependencies, and can be pointed at a variety of package sources (eg: local directory, NFS mount, FTP site) just like apt-get can be.
Why doesn't anyone ever mention urpmi in these package manager flaming threads?!?! Are any Mandrake users out there using urpmi, or is everyone stuck at 'rpm -Uvh'?
It's called apt
*shrug*
Apt is a great thing that helps make debian what it is. Availability to other dists can only be a good thing
no sig.
You completely misunderstand the purpose of the package management system. Any such system, whether rpm or deb, makes hacks like stow unnecessary.
The purpose of a package manager is to regulate the installation, upgrading and removal of a particular application in a particular format, be it rpm, deb or tgz. Among other things, Stow allows easy un-installation of problematic packages and prevents files and links from being deleted by mistake. While you may consider these features unnecessary in a package management system, i consider them an enhancement.
SEO Copywriter. Just Say ON
I think rather, that this is another illustration of how open standards are wonderful. That apt can be (relativly easily) ported to take another backend system is a testiment to great people, doing great things for ALL linux users. Not getting caught up in the bickering between vi(m) and emacs, rpm and deb, redhat and mandrake, etc.
Zapman
It won't work as flawless as Debian, just because there isn't many rpm packages as there is deb packages.
The thing is, Conectiva is saying that they invented apt. And by doing so, they are illuding their users (mostly from Brazil, because they are a Brazilian company). And their distro is not that good either (it's actually redhat with different instalation).
ehh.. do you know him personally ? i dont see the points, you are mad about.. he didnt say beos is better than linux... he didnt even say bsd is better than linux and he neither said nvidia-driver and reiserfs is crap.. in fact he said that the nvidia-drivers are the reason he wouldnt use bsd.. so whats your point apart from offending /.ers ?
The result... after a couple of months installing softare or hacking a little the machine, RPM databases become inconsistent and useless, and you must go back to the ancient but reliable tar.
It's really bad that after 1 year a packaging format (and/or local database) become useless due to inconsistencies or newer packaging versions*. It deter expert users from using those formats and my mother from updating her system.
* And better not to talk about dependency nightmares in old libc5 systems.
--ricardo
sgis ddo ekil t'nod i
Lets look at some of these problems... lets say I want to have an mpeg player installed, one that's based on SMPEG. SMPEG uses SDL to render to the screen, so that will need to be included. Now in turn SDL has the *option* (when compiling from source) to include OpenGL support. Now we've got a problem - as a distribution maker do we have our SDL package include OpenGL support (and require Mesa) or not? For someone who just wants to be able to play mpegs and is never going to do any 3D work the idea of being forced to have Mesa installed and taking up space is insane.
The problem is that RPM just has a list of package requirements for each package. A list of other packages that are needed - what it needs is a list of things each package PROVIDES as well, so that several versions of the same package can be produced, with different options etc
Probably. Linux's 1.5% of the market dwarfs BeOS's 0.5%. Its neat to see people fighting over the crumbs from Windows' plate.
Your numbers are almost certainly wrong, but point taken. Yes it is ironic that I am arguing market share (popularity) when there is a 12 ton gorilla looming over it all. I don't consider Windows as an "alternative". Windows to me is like our current Hard Wire telephone infrastructure. It's there, it works, and every has it, or can get it easily. In this anaology linux would be like your wireless or cellular technology, or even DSL or cable -- whatever. The point is, who cares what the percentage of cellular is to hard-wire phone? The point is that cellular is growing very rapidly and has huge investments from many different companies, not one or two in the case of hard-phone technology.
<I>Why would you bother mentioning that something was both subjective and unsubstantiated?</I>
Well, since your imagination fails you, here's a simple hypothetical:
-Someone makes a subjective statement.
-It is reasonable to assume that a subjective statement can be made in the current case.
-It is furthermore reasonable to assume that the subjective conclusion made is reasonable and even logical.
...Given that, why is it too much to ask for a substantiated opinion? (I'll give you the benefit of the doubt on this one, you obviously rushed your comment out)
<i> Thats the thing about Open Source software. No one ever says "I'll be fixing that problem shortly." All one ever hears is "Someone else will probably fix that sometime." The movement has a handful of coders and a whole bunch of dead weight.</i>
You are generalizing. I was referring specifically to the case of nvidia's drivers and reiserfs. Wile I would even go so far as to say that your claim about the linux community is true (that they exaggerate the idea that coders are constantly fixing problems), it is certainly not true in my limited, perfunctory example.
<i>Invest in a copy of Windows 2000, both of you. You will be much happier, and will be much more productive.</i>
I appreciate your interest in my well-being, but I beleive it has more to do with your resentment of linux and your cynical attitude that windows is everything to everyone. I am very happy with linux, thank you very much. As for my productivity, well I'm living at home with my mom, I'm 22, and I don't have a college degree. ie, it's irrelevent. Sucker.
I think what is needed more than this though is an easier way to create rpms or 'packages' in general. Say I download a source.tar.gz file. I have no idea what files this will install or where. If it uses configure I may be able to pass it enough switches to install it in /tmp/test or something and then see what it installs, but if it does not than I am just guessing. It would be nice to use journeling file system and package installing to create a package management system that can actually install a tar file and keep track of what files were actually installed and where and then if need be remove the package, by moving back to a point before the package installation in the journal. If this is even possible. Windows is moving in a similar direction, where you can take a snapshot of the system and then go back to that point in time if something happens in your system. However you must take the snap shot, or configure it to automatically do so.
I don't want a lot, I just want it all!
Flame away, I have a hose!
Only 'flamers' flame!
That does not really answer my question about Slackware:
- automatic partitioning for people who don't know Linux, and after he/she learns more about Linux, it can easily be done. - automatic hardware detection like Redhat, Caldera, Mandrake, SuSE(where? where?) This saves a lot of time, man!
- GUI partitioning tool during install that lets me to resize the partition like DiskDrake (from Mandrake) so that I don't have to buy the expensive Partition Magic. This is important since a lot of Linux newbies are so used to GUI tools from Windows.
- automatic dependency install like Debian (apt-get) and Mandrake (urpmi)
- automatic modem detection like Redhat
- *_Complete_* configuration tool like webmin or Linuxconf. This saves a lot of time. I know that LinuxConf was not created specifically for Mandrake and Redhat, but a lot of Slackware users say that people who use LinuxConf are dumb. The fact is, it saves a lot of my time. Yes, I can do everything by hand, but I'd prefer to use webmin/LinuxConf since coding and time is more important than editing config files
Slackware is not bad, it's just it's not mature yet. Look at Debian with its superior apt-get. Look at Mandrake with its urpmi, auto hardware detection, good configuration tool, saves a lot of time. Caldera installation is the easiest and the most user friendly. An easy installation process != not 31337. It means the programmers who design the installer is much smarter than the one that can't code an easy install process.
I said this because I'm tired of Slackware users who often bash Redhat/Mandrake/Caldera/SuSE users and says,"I configure everything by hand, since you can't and you're dumb, you have to switch to Slackware" but can't do anything but editing by hand with vi. As a comparison, I can code graphic routine in Assembly (Intel x86), but I don't brag about it like that and say that Delphi programmers are wimpy because they can't code Assembly. If a person wants to do a hard time being 31337 editing configuration file, like I said before, Microsoft Windows NT is the answer - Registry Editor.
And I don't have to subscribe to a mailing list if I want to upgrade my packages. I just simply run apt-get (for my Debian) and Mandrake Software Update and it works! Debian, Redhat, SuSE, Caldera, and Mandrake security department very often announce the updates via LinuxToday and Bugtraq whenever there is a security problem.
Caldera, Mandrake, Redhat, SuSE detects all my hardware automatically (including my soundcard, video driver, ethernet card). They are mature, IMVHO
I had a chat with some people who said that they want to switch to Linux but were afraid because it is said to be very hard to install/configure, thus reducing the productivity. If Linux want to be used widely, then we have to stop the mindset "it can be edited by hand". We were chatting and when I mentioned great stuff about Linux, and some of them say "We want people to be productive, not trying to figure out how to do this and that and configure this and that and later reading the man pages for 5 hours and so on etc etc etc" and "it does not detect my hardware automatically, so I have to do it by hand bla bla bla". First, I was annoyed, but later I realized that what they say was true though, and it gave me a lot of insights. That's why Linux has to be luser-friendly as well. Remember that there is a lot of people that have limited learning curves, and we need to embrace them as well.
EOD (End of discussion)
-- Microsoft, Inc. http://www.microsoft.com
>My point is, both GUI and ncurses config tool is >good, hardware detection is good. I just can't >seem to understand 31337 people who waste a lot >of time for editing by hand. They are good, but only if they dont keep you from knowing how to get along with out them. Things break sometimes, and if you can't fix them without the tools in X, or sometimes even the ncurses too you can be in a load of trouble. Saving time is great, I use redhat at work, and all of the time saving configuration tools it copmes with, but I still can get by without them. That's when they are useful
treke
Here's the deal. Slackware is a distribution. Just a plain and simple distribution. A collection of the linux kernel, and various other software packages that would make up a unix-like system. Along with a few basic config files to make everything workable. As far as hardware detection, that is left up to the user. Actually, the kernel detects most hardware automatically. I would also think most people using linux would already know what type of sound, video, and ethernet card they have. With most new hardware, you don't even need to configure IRQ's or whatever. For the soundblaster live, all you need to do is modprobe emu10k1, or just uncomment that line in one of the startup scripts.
But hey, im not saying the other distributions are bad. It's all a matter of preference. If someone asks me what I recommend, I will say slackware.
The real problem, o lame foreigners from the Metropolis that doesn't know what happens in the colonies...
/etc/apt/sources.list!
1) Conectiva is known as a great... Red Hat copier. Even the bugs.
2) Their former distro (Conectiva 5) was a great failure, a buggy piece of code.
3) They're trying to differentiate themselves from RH... maybe because people preferred to buy RH discs from Cheapbytes rather than shelling out US$45,00 and buying their boxes.
4) They BOUGHT nearly all the Brazilian Linux community. The main news site in Brazil is run by a Conectiva employee. All LUGs are unpaid PR departments of Conectiva. And so on. And the lonely ones trying to fight against this Borgization (kudos to Bruno 'Buick' Collovini for denouncing this) are called nuts.
In theory, porting APT to RPM is a great idea. But...
1) It was a bad work. Really. E.g., they made a so-much mess in
2) It uses an old version of RPM. RH 7 uses RPM 4, they still use RPM 3.
3) They don't touched the RPM problem: the confusion that is their database system.
APT is used by Conectiva as a update tool. Most Linux distros have now very good update tools (Mandrake Update is great, RH up2date will be a great one also).
APT is not a update tool. APT is a organizing system, using the dpkg facilities to maintain the system healthy. APT as a update tool is a sad move.
Not so nice, Slashdot trolls. Reality is ugly.
(Note to Conectiva propaganda people: FODAM-SE!)
Cesar Cardoso can be found at cesar at zyakannazio dot eti dot br (or at least I believe so)
Apt really rules, I thought, console-apt, don't known that one. So I typed apt-get install console-apt and it was on my system ...
What good is it to have different distributions if the distributions are all alike? Of course there's one of them I'll pick for my own use. And the reason will be because it doesn't do it the way the other packages do. What I'm trying to say here is please don't try to force all the packages to be like. I don't want a Linux melting pot. I like diversity.
now we need to go OSS in diesel cars
It's kind of like vi steep learning curve but once you start using it and actually READ the help files and ask questions to people who actually use it, it all begins to make sense and you wonder why you've spent so much of your life without it.
> What we need is a packaging system that can correctly detect whether or not dependent packages are installed without having to have a database
You've just described FreeBSD's ports collection. Every port I've installed checks for files (using the standard binary and library paths) and not packages. Ports is not perfect: it builds BSD packages, which are so primitive and hard to manage, I don't even bother uninstalling them, i just write new versions over them (so it effectively has no version control). It'd be nice to have it build RPMs instead, even if rpm isn't the best tool out there.
Best of all worlds would be something with the rich command syntax of rpm, the package flexibility of solaris packages (where you can edit the packing list of an installed package) and the script-like flexibility of ports (which is all makefile-based, so you can edit the logic of individual ports, or all ports)
I've finally had it: until slashdot gets article moderation, I am not coming back.
Don't believe everything you read, either the author of that book had only seen the most complicated spec-files there is, or then he is an idiot.
At simplest, it is not much more than name and version... some other "header"-type information is required, of course adding files is nice so you can actually remove the package with rpm even though you have installed it using some other way.
RPM-specs can be complex if required (compiling some of the most stupid packages is quite a pain in the ass and rpm has to handle that too..), have macros and things, but they certainly don't HAVE to be complex if you are dealing with simple package or no actual compilation process at all.
Redhat's source packaging is actually nicer -- they don't have the stupid one patch limit that Debian has. The main thing RPM lacks is dependency-tree generation.
Uhhm, hello? That is what a package manager does! That's the whole point of even having a package manager.
___
___
If you think big enough, you'll never have to do it.
--
This space left intentionally blank.
You know, if you read the help file or know vi you'd find you can simply search for packages in dselect OR from the command line
apt-cache search task-helix-gnome
Dont put in the time to knock it if you havent put in the time to learn it first. I wouldnt consider the "task" selection setting up an entire workstation of unconfigured junk to be a good thing 90% of that stuff you'll probably never use and may pose a security issue. When I install debian I have a basic system that I can build from the ground up. Notice I said when I install, because during the install you have the same option to install major subsections of packages window managers c development etc etc.
"Scalability. I want to be able to treat a set of packages as a single unit."
.|` Clouds cross the black moonlight,
apt-get install task-python-dev
"source access. "
apt-get -b source foo
"Source Format."
Note that apt-get source uses 3 files:
xemacs21-gtk_20001018-1.diff.gz
xemacs21-gtk_20001018-1.dsc
xemacs21-gtk_20001018.orig.tar.gz
or whatever.
"Source code references."
I don't know how this is possible in general terms. But doesn't MD5sum help?
~Tim
--
~Tim
--
Rushing on down to the circle of the turn
How sad, their text installs were nice easy and set up beautiful, if not secure, systems. I loved their eye candy. So sad, too bad.
The more I use Debian, the more I like it. RH looked to be hiding more and becoming more restrictive, while Debian just feels so much more informative. There seems to be little difference between the way things were done in 2.1 and 2.2, but instalation was much easier.
That's how I feel, but there may exist people who feel otherwise: for them Debian will be superior even if other distributions adopt APT. After all, if the packaging alone was not enough to make me switch to Debian, I'm willing to assume it may not be enough to make other people switch from Debian.
No shit Columbo. Read my original post again, it states Apt should imitate GNU STOW's safer software management features.
I'm getting tired of spelling it out for you RelliK.
SEO Copywriter. Just Say ON
© 2000 Ilmari. All ritghts reserved, all wrongs reversed
© ilmari. All rights reserved, all wrongs reversed
Debian IMVHO should work more on getting the installation right. Those who brought us wonderful tools such as apt and the whole Debian packaging system should be able to add an optional graphical install that installs X and configures networking after the user selects his/her choice of software.
About Mandrake: Its my favorite distro so far... Its still rpm based, but it has managed to keep a safe distance from RedHat. Its user-friendly facilities (install-configure-etc) are without peer. Check them out here.
No sig for the moment.
Although this is OT - yes, it was a very nice film, and I liked it alot,
because you could see how stupid those rightwinged idiots are (I talk about EXTREMISTS here, remember).
cya
YerMaster
You're addicted to the net when
- You call 911 when your ISP goes down
nor did I say those things.
I am saddened by your misunderstanding of my commentary on be-fan's response. I guess I wasn't sufficiently clear.
I'm not even necessarily mad.
To say that X is better than Y is a totally unqualified comparison, and is meaningless to me.
Personally, I think ReiserFS and nvidia-driver are very good. So you misunderstood that. I was criticizing his response that reiserfs and nvidia-driver are not standard components and therefore show that linux's assumed standards are lacking, because both of these products are top-class.
You sound like a friendly chap. Maybe a bit out of your league, but that's ok.
Perhaps RPM is great when you make certain everything you upgrade is done with RPM. The sad fact is that an RPM file usually lags behind by hours or even days, making it necessary to compile source and let the Makefile blinding do the install, throwing the whole RPM database out of whack. And if you have to patch source, as I occaisionally do, then you're screwed.
I used Redhat for 3 versions (5.1, 5.2, and 6.0) and it sucked and didn't show any signs of getting better. Half my problems were with the RPM database being screwed up (saying I didn't have dependencies I really did have, and so on). The other half were with the screwy Redhat rc files, but that's another thread. I tried Debian but never got to see if APT would do things right because the installer in Debian was screwed up (they have announced fixing it, but it's too late for me now). I'm back to Slackware and trying OpenBSD. I'll probably have time to give Debian another look in 2001 sometime.
now we need to go OSS in diesel cars
But that's exactly my point. The database is the thing that saves you time because it knows where everything is on the system and keeps that information in an easily searchable format. I can't see how a packaging system w/out a database would be less hassle and save time. Everytime you had to install a package, you'd couldn't search the database to find the relevant information that you needed. You'd have to search the filesystem.
Or maybe I'm just missing what you mean. can you elaborate?
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
I see a great difference between the way I approached the problem and the way he did. My responses have been geared more towards finding the truth. His were of unconditional fanatacism. I'm still distressed by the way the BSD folk downplay Linux, however I am seriously considering installing FreeBSD. A lot of the software I run comes from BSD anyhow. I have one outstanding migration issue however.
Package dependencies exist for far more than just libarry requirements. RPM actually does have support for saying that a package requires a certain file to exist. Most RPMs use package dependencies rather than file dependencies though, because they're more reliable and can, in general, express more than file dependencies
For example, suppose a program relies on a specific version of diff. What file should it look for?
Even if you do work out how to use dselect (I tried) it's still a complete pain. Just how many packages are there in Debian? Do you expect the user to read the description for each one and decide whether to install it? This problem would only get worse and worse since the number of packages tends to increase by 50% with each Debian release.
The Red Hat approach of 'install 900Mbyte of crap' is better. I don't want to become some expert Linuxologist knowing exactly what packages are on my system and what each one does. I just want the machine to set up a working system with a good selection of packages. If some disk space is wasted by installing crap I'll never use, that's not a problem - disk space is cheap. I'd rather waste disk space than waste time.
Debian 2.1 (which was the last version I used) did have an option to choose from preselected lists of packages for various 'tasks'. This is similar to Red Hat's installer which lets you choose sets of packages like 'NFS server' or 'GNOME'. Maybe for some purists it's important to have something like dselect available as well, so you get really fine-grained control over what is installed, but not for me.
-- Ed Avis ed@membled.com
Just take a look at http://www.olinux.com.br/introducao I heard in the Debian-br lists (http://debian-br.sourceforge.net) that they have said they invented apt, during their Conectiva Linux 6.0 launch.
Eil's post isn't flamebait (as moderated). :-)
The guy did indeed copy and paste from the original (I'll assume he didn't have the ability to 'cut')
dylan_-
--
Igor Presnyakov stole my hat
Another reason why attributes should be integrated into the file system ;) I say let it program install and issue a warning allowing the user to check for the correct version.
RPM blows goats when it comes to dependencies. For example, if you compile XFree86 from source, then ever after you'll get missing dependencies. Deping on packages isn't a better idea, but a lazy one. Developers take the lazy way out and say they need XFree86 instead of each individual library. That's just the truth of it.
A deep unwavering belief is a sure sign you're missing something...
And the years of work invested in, and tons of expertise using, coding, etc for rpm and deb would of course not be part of their decision. They'd just want to jump onto whatever bandwagon happens to roll by.
The current Slashdot moderation system is made by gay communists!
My feelings exactly... plz check on my post above.
No sig for the moment.
You can put up the entire archive on nfs and check md5 sums all day if you like peruse the source, run a virus checker? etc etc etc. apt sources can be just about any method of data retrival you can think of...ok maybe not carrier pigeon but that's too slow anyways.
rpm --rebuild something-0.0-1.src.rpm
All the compatibility of source tarball, all the convenience of integration with the package database.
1st Law Of Networking: Loose ends are bad, termination is good.
WWJD? JWRTFM!!!
I really love apt on linux, but I -technically- love BSD's /usr/ports system more. Ports -always- builds the software from source, gotten off of one of its many home sites on the net. It also allows for distribution specific patches (for security, bug fixes, portability fixes, etc.) as well as specifying *compile time options* (the specific rant mentioned above) for each package.
Granted it is always up to the port package maintainer to determine how many compile time options they'll throw support for in the ports package Makefile, the option is always there. A good example is the editors/vim port, which by default builds the whole rediculious thing with X support via libgtk and all that brings in. However with a simple make option, X support can be disabled at install time and your dependencies go way down.
Do you want binary distributions to avoid building from source? Ports can do that as well, but you'll lose the ability to choose what you want built in. It will always be that way unless people want to make a system with subcategories within a particular package. (gross)
The only drawback with ports is that there aren't as many up to date available packages. This is simply due to the number of monkeys out there creating them.
An extension to autoconf or an autoconf like tool that could auto-generate ports, rpm, deb, and plain tar.gz packages from a single config file would be nice.
Ok I must be wierd. I actually like dselect.
I guess it's an acquired taste like Guinness.
134340: I am not a number. I am a free planet!
I just wanted to congratulate Conectiva for all the great work they are doing.
I'm not sure if everyone knows that Conectiva is a Linux distribution from Brazil. I started using Linux after buying one of their first versions -- I went to a small house in the city of Curitiba, in 1998. My fisrt thought was that I was in the wrong address, but a nice guy opened the door and sold me a box with their distro for something like US$ 25.00 (R$ 50,00).
At that time I could never imagine that they would have such a (major?) role in the Linux community, such as trying to unificate all the packaging systems. I couldn't imagine this first because I knew nothing about Linux, but specially because they are from Brazil, and they were a really small distribution.
In spite of that, I now use Slackware as my favorite Linux distro, and I'm not very fond of RPMs. I think that the standard packaging system should use the source code -- because it's much more portable. Of course there some programs that take too much time to compile, I believe. I have never compiled X, or GNOME, or KDE, but I think it should take a little more time than the average user would want to waste.
Anyway, I just wanted to say "congrats" for all their effort. Keep up with the great work!
--
This space left intentionally blank.
Umm.. the Realtek 8139 drivers work for me in with the 2.4.0test5 kernel... and I use two of them in the same machine :-P
Just say you like FreeBSD better next time.
What we need is a packaging system that can correctly detect whether or not dependent packages are installed without having to have a database. Inevitably, the database will get out of sync the moment you have to compile something from source because no .deb or .rpm file is available right then, or because you have a local patch to fix a bug you need which isn't important enough for enough other people for the author(s) to fix right now (or maybe is to complicated for them to figure out how to roll it back in without breaking things for other people that you don't happen to need to worry about). Once the database is out of sync, then new problems come up, and those are easily fixed by forcing an install or installing from source, and then it just gets worse.
Without a database, it would mean the installer would have to have a way to detect whether the dependent thing is installed or not, and in the correct version. I won't say that would be easy, but it is what would be needed. Until then, based on my past experiences with Redhat's RPM, I won't at all be interested in a fancy packaging system.
now we need to go OSS in diesel cars
This argument works just as well with debs as RPMs. The only problem being a lot more packages provide a specfile so you can rpm -ta foo.tar.gz than provide the debian dir. And while official rpms do lag behind the release, this happens with debian as well. And for those packages which don't have a specfile, it's _usually_ trivial to change the specfile (yes, you do have to dl a bit more) for the current version. Back when I had time I managed to keep a RH5.1 (originally) system up to date until I found something better to do.
Debian just lets you be lazy and not have to compile things to stay up to date.
As for the rc files, They look to be about the same as debians anyways.
For someone who just wants to be able to play mpegs and is never going to do any 3D work the idea of being forced to have Mesa installed and taking up space is insane.
This one of the things that drives me nuts about FreeBSD ports when building stuff that has an XFree option. Some stuff gets marked as needing X when it really doesn't, only because the maintainer or general usage assume you want the X parts. Expect is a good example -- Expect wants TCL, which leads down the road to building X. I got lazy when I first used ports and loved the dependency building, until I saw X getting built on a machine that didn't even have a monitor attached!
I've gotten to the point where I build around it and generally avoid that little trap. The general solution for packaging systems that build from source is some kind of interactive gizmo that lets you pick some compile time options that better match your preferred build. But its much harder to do in the binary package world as binaries built expecting a specific library or application dependency.
This is a great next step for rpm based distributions. However, the cleanliness of debian packaging is only part apt.
Most of it comes from thorough policy and packaging guidelines from The Debian Documentation Project. Until other distributions develop such comprehensize packaging policies, the package will not interrelate as well (read - dependency problems will screw up apt). Debian maintainers spent a lot of time thinking out these compehnsive guidelines.
I can rarely upgrade Redhat distributions cleanly without tons of rpm commands ignoring dependencies - however, I find this trivially simple with debian. And the capabilities of dpkg and rpm offer no advantages. But the packaging policies do.
Apt will help a lot though.
This also shows that competition in Free Software is good. If debian innovates, the innovations can be copied to rpm based distros. And everyone wins.
I was inferring from the text what you say he never said. It is literally true that he did not say them, but it is nevertheless possible to infer that he meant them. I ain't gonna go into it -- tough.
Sorry to hear you couldn't install the nvidia drivers correctly/optimally. Linux isn't for everyone (thank god).
I agree. Freebsd is a solid work. So is linux. Is it arguable that overall, freebsd bests linux? Maybe. I don't care. I use linux 2.4. Linux 2.2 is dead.
I suffered the first two errors mentioned, after the upgrade failed. The upgrade had some kind of network problem. Suffice it to say that I was dissapointed and very supprised after the third attempt had failed. When I had trouble retreiving the corrected installer, well that was four strikes. The upgrade was a tease, because everything that did work, worked much better!
Debian, though more difficult to deal with and not nearly as beautiful or wizzbang, worked in fewer tries. Their ftp and http instal was also very impresive and open next to the problems I may have had with Red Hat's ftp bug fix (it might have just been bussy).
I will not give or even recomend 7.0 to anyone, but would recomend they wait for a while until they fix some of these problems and release 7.1 Don't get me wrong, Red Hat does lots of things right, but so does Debian and right now I'm going to play with it. What's the use of choice if you don't use it?
By the way, this little bummer could have embarased me. I'm happy that my boss did not see 7.0 blow up when I tried to put it on a machine at work (one strike and you're out that time!). I work in an MS shop, and companies like RH and Correl are my only hope to escape the talking paperclip. If the first thing the PHB sees is a failed install, my hopes would get dimmer fast. That little box (a P90!) now runs RH6.2, and it's running aps and collecting uptime that NT never knows, a much better demonstration. I want to get much more familiar with Debian before I pull a stunt like that in front of people.
Yup, that's what I'll be working on when I get some time. I dl'ed the pdf and most of the files.
Problem is, the first time I tried it was to cross-compile. Got a little ugly, and I gave up.
But this is definately the route I will be going. Standing on the shoulders of people smarter than I will get it done that much faster.
Jesus was all right but his disciples were thick and ordinary. -John Lennon
--
Create two SDL packages, one linked against (and requiring) Mesa and one not. Both of them will satisfy SMPEG's SDL dependency. The user can choose which to install.
Well then what's really needed is a way for you to easily tell the system, "I have XFree86 version x.y". Or better yet, make install should do the right thing and add the installed package to the database.
Get a grip. Take 2 seconds to read the help file dselect displays and you would understand it. You just see tons of software and get confused... "oh take me back redhat guy, I'm sorry for ever doubting you, and please install 900megs of crap I wont ever use or understand, but at least I'll never have to think about it. It scared me!!! using the arrow keys to scroll up and down, then using the minus key to de-select software I dont want or need, or using the + key to add new software. Its so hard!! Oh gosh, and those dependancies, gee that's hard, I mean, its confusing that to run foo I need to install foolib? dont even mention those confusing descriptions, full of technical computer jargon and whatnot......"
If it is so bad, how about at least describing what a suitable replacement would look like? But your replacement had better run on a serial terminal or a basic VGA display.
The current Slashdot moderation system is made by gay communists!
barneyfoo or Mojo Jojo?
You make the call.
--
Forward, retransmit, or republish anything I say here. Just don't misquote me.
Have you ever used apt and dpkg? Then you'd know what you're saying is untrue.
The current Slashdot moderation system is made by gay communists!
- The multi phase installation. Packages are unpacked and configured in
different steps.
- Maintainer scripts. Debian has a rich and well defined set of scripts a
package can provide in order to leave things configured. They stop and start
services, check the system, update files, etc.
- Strict policy. Debian packages are carefully made so as they work
together. There's a long policy document that specifies what should happen,
how and were, so: no suprises from that new package.
- Virtual packages. A package must be able to depend on certain
"interface" or capability being present in the system, without having to
know which package provides it. E.g.: if a package wants to send a mail, it
will use the tradicional
/usr/sbin/sendmail interface, and depend on a
package wich provides mail-transport-agent.
- Drop file dependencies. They are dirty and evil, as everybody knows.
- All packages involved should be of high quality. There's nothing you can
do with all this measures that will stop a broken packages from giving
trouble to users.
- Several "subpolicies", so emacs, perl, sgml, etc. subsystems could work
together, trigering the registration, compilation, etc. of things when
packages are installed or removed.
- A way for competing packages to be installed, this is made in Debian
with alternatives and diversions.
- Config file handling. The system should never overwrite a config file.
In Debian, dpkg checks if the file has been modified since the package was
installed, and it will ask the user if the package wants to install a new
version. The user could then diff the files, edit, accept or reject the new
version.
A lot of work, perhaps several years... If these are the recognized goals of a distribution, so we should drop everything and make Debian a standard.. =).I think that most people who own Red Hat are likely to upgrade via the net anyway, even if simply by downloading and burning the isos. I think Red Hat will do whatever they can to make a better distro, and will add atp as soon as they have the opportunity.
"The question of whether a computer can think is no more interesting than that of whether a submarine can swim" -EWD
occasionally segfaults, but usually just upon exiting
Do you have any coredumps? I haven't managed to catch it in the act yet..
Daniel
Hurry up and jump on the individualist bandwagon!
First: Scalability. I want to be able to treat a set of packages as a single unit. It becomes unmanagable to set up a development environment for a particular product by requiring the installation of a dozen packages on top of a "stock" O/S installation. I've written a small Perl script to help me do this (since a script inside of an RPM spec file can't call RPM recursively due to its database lock). It supports notions of package set inheritence as well (so the foo development environment can include the generic development environment).
Second: source access. In a commercial environment, we can't go downloading and building packages from an external site. We need to ensure package consistency, and so cache all packages in our source code control system. It would be nice for a packaging system to allow specifications of multiple alternate source locations, and insisting on a particular one. It would be nicer if the package management system supported local or nfs path specs to such source. (RPM looks like it doesn't).
Third: Source Format. When building packages that we have not modified a tar or bzip source code archive is fine. However, for our own packages, we'd like to build from non-archived sourc code directories trees within the source code control system, since that's how our source code is managed.
Fourth: Source code references. When we include 3rd party RPMS of GPL code on a product distribution CD, we of course, have to also provide the corresponding source code on a companion source CD. It would be nice to match binary RPMS to source counterparts, and audit the match (so we don't have to build all such RPMS from source).
You could've hired me.
Let's see here...
Tarball method:
# wget this_package.tar.gz
# tar xvfz this_package.tar.gz
# cd this_package
#
./configure: whoopsey! a problem happened but I can't tell you what it is!
(hours later)
# make
(several warnings, possibly a fatal error or two)
# make install
RPM-enabled APT:
# apt-get install this_package
(does everything)
(package is installed)
I wonder which one is more complicated.
My flock, divided and driven to the wind, much suffering have you endured. Your pain, your anguish, all have come unto me. Today is the day that our brethren shall remember, the day that our ancestors will look upon from beyond the mortal coil and be proud.
Today is the day of unification.
Those of you who useth the APT, rejoice!
Those of you who useth the RPM, rejoice!
There shall be packages and free software for all. Dead is the failed symbolic link. Dead is the day of open software from a heretic distribution. Look around, and be filled with our common strength. United, good shall reign upon the earth, and there will be no fscking.
So sayeth the king!
And there was much rejoicing.
--
What happens when you outlaw guns
I think it was more like all of andover.
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
* Assuming Andover has another $100,000 to toss away on a contest with rules and vote counting that make Palm Beach County look like a beacon of consistency.
A program that converts between the rpm, dpkg, stampede slp, and slackware tgz file formats with ease is the little-hyped Alien . Apt is swish - especially now when it understands a major file format like rpm - but it would be the cats ass if it had the package conversion capabilities of Alien. Apt should also imitate package management routines like Encap and GNU STOW, pm's that essentially isolate packages, installing programs in their own directories and ensuring cleaner and easier removal. With those killer features, Apt would indeed be the Linux standard, regardless of the distribution your using.
Escape from DLL Hell!: The ultimate Package Manager Howto
SEO Copywriter. Just Say ON
Yeah, Slackware is very l33t. Mandrake is not 31337 because Mandrake, Redhat, and Caldera automatically detects hardware, because Mandrake has its own partitioning tool similar to Partition Magic. Maybe Slackware even has a super 31337 partitioning tool that doesn't even work. Mandrake is not 31337 too because 8139 driver works in the hackkernel 2.4. Mandrake is lamer because Slackware doesn't have the GUI tool like Lizard, moreover, Mandrake is luser friendly. I think Slackware is the best Linux distro ever which has a lot of functionality. I must switch to Slackware because it hasn't updated the security problem forever. I think Slackware has a real guts, unlike Redhat/SuSE/Caldera/Debian that keeps updating the package and announces advisories if there's a security problem.
I'm just going to stick with Slackware because it's a very 31337 distro, super uber elite. I think I will just use my super elite Microsoft Windows NT4 server along with my uber elite Slackware Linux.
-- Microsoft, Inc. http://www.microsoft.com
BAD INTERFACE is without question the only reason why debian is not the dominant distro. Someone really should fix this. Make the keystrokes consistant on every page and TEST it with someone who doesn't already KNOW it.
dselect can be a pain sometimes (though it's not so bad once you're used to it). Personally, I prefer to just apt-get install foo instead.
Having the database in human readable form is a huge advantage to me. It makes it much easier to manipulate the system with simple scripts.
Part of what's great about apt and dpkg is that the dependencies are sane and the install scripts in the packages generally do the right thing. It will be interesting to see who gets that right and who doesn't as RPM based distros start using apt.
Does the scope of the LSB cover anything that apt might play a role in?
If so, what are the opinions out there, with apt inclusion into LSB?
The LSB is very important and will go very far to discounting the naysayers (SUN, Microsoft among them) that linux will deteriorate into disparate competing factions that are mutually incompatable.
I use apt every day and consider it a vital part of my GNU/Linux distribution. If it becomes a part of any LSB standard then everyone else can enjoy the drug-like high of first experiencing apt goodness.
If they are unhappy with the rpm instalation system, why keep insisting on being redhat based?
.deb packages to .rpm packages?
They have ported apt. Now what? Will they convert all the
It's easier to be Debian based. That's my point.
In your opinion. That opinion is widespread but certainly not universal.
Nope. What you say is true of rpm. The main feature of apt that debian heads think makes it so much better than rpm is that it actually does grab the dependencies for you. A major factual error on your part.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
This is great for Linux, because we are one step closer to having a standard for installing packages. Of course, it's almost certain RedHat would oppose any attempt to get rid of it's inferior RPM format. That would be a shame, considering that Linux's greatest competition comes from each other, and not say, Microsoft. I think the *BSD's are getting it right by putting their differences aside and embracing OpenPorts. Maybe RedHat should do the same thing.
--
The World is Yours.
I never use dselect. I use a combination of apt-get and apt-find (which is in the console-apt package)
I too had such problems in the past until I learned the following: There are a couple of things you can do to largely alleviate that problem. I hope these tips will help some of you guys out there:
.deb... That keeps your database intact, plus allows you to easily put up the patches source and binary on your web site for others to enjoy.
/usr/local/packagename-version/*/ and modify the ld.so settings for the programs requiring the patched version. That's how I've been using Xfree 4.0 and 4.01 since long before it was aptable, and now still my database is 100% intact.
- If possible, it's best to make all patches with 'apt-get source' followed by doing the patch and a 'dpkg --buildpackage' followed by installing the newly generated patched
- Alternatively, keep the original package installed (the patch might break other programs depending on the package), and install the patched binaries in
--- Hindsight is 20/20, but walking backwards is not the answer.
Firstly well written configure scripts are rarely a problem, and well written code makes just fine. Assuming you aren't trying to port it, of course, in which case you should be expecting a few problems.
Secondly, but perhaps more importantly, you're assuming tarball == source tarball - which is totally incorrect. Here's how it goes with a binary tarball.
wget this_package.tar.gz
installpkg this_package.tar.gz
Much simpler. Yes, there can be problems. There can be problems with other package managers too. In my experience, this is the best. If you like another one, that's fine, use it. But don't go around pretending to know how tarball package management works when you don't - or deliberately building straw men, whichever you did in this case.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
better yet he could go to windows ME where it'll be 700 megs and the only extras that come with it are IE, windows media player, and some other nice purty enhancements
Personally I'm seeing quite a bit of activity in the LSB and the various RPM-based distros are so compatible with each other that it shouldn't be all that difficult to get things to work.
Disclaimer: I work for Conectiva and even run an ftp mirror of Conectiva 6.0 ...
The RPM to .deb convertor (forget it's name right now), would convert the RPM's, but 9 outta 10 would segfault on me in Debian. Which I attributed to the fact that any given RPM program was likely compiled for RedHat. Maybe what we need is an easier way to get things to reliably compile..
That's true. Like the fine xmms requiring me to have Mesa installed just because of the fine plugin... Well, --force is my friend, but there should be a better way.
If a package uses autoconf, the libraries it uses can be determined by its configure.in; any headers/libraries it cannot compile without can be considered dependancies. In most cases, it should be possible to easily extract this info from the configure.in; 'twould indeed be nice to have a standard means of spec'ing it, though, so that it would work in _all_ cases.
After binaries have been compiled, ldd can be determine to determine required libraries. This is how rpm et all determine dependancies which aren't manually defined by the author of the spec.
Admittedly, these don't work in all cases -- but they're certainly Better Than Nothing.
Spend one week with apt and you'll never want to use anything else again. It's a rare occaision I have to compile from source because 9 times out 10 there's a deb in apt. Consider clean disk to full install I can put up a webserver capeable of running slashcode in literally 30 minutes or less have fun hunting down the rpms for that or worse the source. I'm not saying it's a perfect system but it will focus time on what should be focused on applications. If linux is to gain ground this is a step in the right direction.
One of the things that make using BSD a joy is the ability to pick a package (or ports), start the install of said program, and, (assuming the maintainter has done their job) get all the dependancies installed auto-magicaly.
And, when some linux distro (odds are Debian, because they had the taste to copy the proven success of the BSD package management. Debian even had the taste to suggest a BSD kernel patched into their userspace.) starts tracking the kernel (and other parts) in a CVS, Linux might have a chance of approaching the quality of BSD for system administration.
If the BSD OpenPorts project ever ships working code, given the liberal BSD license, some Linux distro will pick it up/create some form of rpm/apt patch. I doubt it will be RedHat or Debian 1st. Simple programmers ego prevents them from being 1st.
If it was said on slashdot, it MUST be true!
the DEPENDENCIES... When I used RPM based distros, I felt like a detective anytime I tried to install a package. I.E. --> Track down all of the packages that package 'a' depends on and install them (+ all of the (child) packages they depend on... and so on) before I can install the package I set out to install....Debian makes it so much easier --- If a package depends on 14 of those annoying PERL extensions -- then by darn it automatically goes out and installs all 14...WOW what a concept!!!
I encourage anyone stuck in "RPM Hell" to give Debian a wirl....(As to you Slackware users out their -- well I wont bother you -- I still have a soft spot for Slack)
sog
(+1 Funny) only if I laugh out loud.
People often get fooled by the idea that Linux companies only want to advance their own distribution, but the reality is that different distro's simply appeal to different tastes (like different tastes of ice cream) and that the Linux companies make most of their their money by services, not by selling boxes of CD's...
In fact, a lot of the apt-rpm things were developed in good communication with the Debian people and most developers here aren't all that happy with the fact that marketing let one "Conectiva invents apt-get" press release out ... they've since been cluebatted and all the other press releases list Debian too like they should ;)
Disclaimer: I work for Conectiva and maintain a conectiva 6.0 ftp mirror... (but since I could get a job pretty much anywhere, I'm keeping my loyalty with the Linux _users_, not with any particular company!)
This should be good news for the people who are afraid that apt-get for RPM is a problem for Debian ... the fact that apt-get has been ported to another package format simply means more apt-get frontends will be available soon, one for
everybody's tastes. And the fact that Debian and the RPM-based distro's are closer together now means it'll be easier for everyone to choose the distro of his/her taste without having to choose for (in)compatibility with other stuff at the same time.
Disclaimer: I work for Conectiva and even run a Conectiva 6.0 ftp mirror...
It took the people here a few months to clean up all the dependancies of every package, but now we've finally got a nice RPM-based distro which has all the dependancies right ...
For me personally (I'm just doing kernel hacking and no distro stuff) this has caused no end to my joy ... since the distro folks got all the dependancies right I'm using apt-get and don't have to bother with system administration of my box any more ;)
Disclaimer: I work for Conectiva and even run a Conectiva 6.0 ftp mirror...
Yes, I do agree that apt is what makes debian superior... But the dselect interface is SO INCREDIBLY BAD that I've never had the patience to finish installing debian, and always wind up dropping back to slackware or even redhat(yuk).
BAD INTERFACE is without question the only reason why debian is not the dominant distro. Someone really should fix this. Make the keystrokes consistant on every page and TEST it with someone who doesn't already KNOW it.
Now we can use apt on other distros. Hurray. I still would like to use debian though, and I know others who feel the same way.
But seriously ... personally I think it is good to have different flavours of Linux that cater to the many different tastes people have.
On the other hand, I also think it would be good if all the distributions would be compatible enough that you can install the same 3rd party software packages on each system...
I hope that Conectiva 6.0 with its apt-get for RPM will bring us a step in the right direction. The main reason I hope lots of people will be using Conectiva 6.0 is that a whole bunch of my friends have spent a large amount of time working on it ;)
But in the long run the only thing that's really important to me is that every computer user will have the opportunity to run that system that (s)he likes most while still being compatible with the rest of the world. It's about usability and freedom of choice...
Disclaimer: I work for Conectiva and even run a Conectiva 6.0 ftp mirror...
I quickly returned to Storm Linux which is, as far as i can tell, 100% compatible with REAL .debs only uses a purty (and quite handy actually) GUI. So long as they leave the .debs alone I'm happy.
Why was /. down?
Search for it. At least on BeOS, a system wide search for a particular library takes no time at all. I doubt it would be much slower on Linux, and when ReiserFS gets the db addons, it might be faster.
A deep unwavering belief is a sure sign you're missing something...
Perhaps "make install" could update the database?
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I think you're pretty close to the mark. Debian has some really good stuff going for it, like the packaging system, the huge collection of .debs and the extra attention payed to security holes/bug fixes/overall tightness.
however, i get the feeling that the people who wrote the installer process just simply could not give a fuck about people who really can't afford to waste days trying to get Debian to work on anything more exotic than your average desktop PC.
Take the RAID experience as an example...if you want to setup a Linux server with a RAID 1 root partition, you have to jump through all sorts of ugly hoops to get it done with Debian...screwing about with single disk installs, marking disks as bad, rebuilding arrays etc etc. With Mandrake, installing the main filesystem directly onto a RAID 1 partition is a default part of the graphical installation!
The hardware RAID fuckup is another example...the Mylex AcceleRAID drivers (DAC960) are part of the standard kernel driver set. Mandrake and others had the foresight to include this driver in their initial setup kernel image, so that it was possible to install onto an array controlled by the Mylex card straight off. Why was it so hard for Debian to do a few time saving things like this?
When you're doing this for a job, you just don't have time to waste making up for the deficiencies of a really really bad installer. A general contempt for users is what it comes down to in the end...why the hell do I have to waste hours and hours doing this shit when other distros get it right in the first 5 minutes of the install?!?!?!
Ummm...ever poked in Debian? gaim, gaim-gnome, sawfish, sawfish-gnome, and the list goes on. For most of the packages you mentioned, they at least tried.
I'm going to go back in my box and will think within the limits of my box: MS Sucks Linux Good I read too much Slashdot.
I have tried it. I honestly didn't see what all the fuss was about, aside from it being cleaner than most Linux distrobutions. I didn't give it that much time to shine though. My reasoning is this: with hope and study, I will be contributing to one of these kernels. I honestly don't like the idea of some random company taking the code I've worked on, modify it, try to sell it back to me, but not even give me the modifications they made (let alone anyone else).
Aside from that all I ever see comming from the BSD community with regards to Linux is a sense of supremecy.
Tell me this.... the BSD License allows sublicensing. Would it be legal for me to GPL the code, while leaving the copy-right intact? If so, I'm having some devilish ideas of my own >:) (If that upsets you, then it's time to change that license)
Dependency management is an important feature of package management systems. It helps keep system consistency, making sure that everything needed for a certain piece of software to work is there, in the expected version. But tools such as rpm or dpkg have limited handling of dependencies. They're limited to figuring what dependencies a package has and telling the user that an operation effecting that package cannot be performed until all dependencies are met. For example, installing the Pingus package could involve the following steps: Download the pingus package. Try to install it; see the package manager complain about missing libraries called libClanLib.so and libSDL.so. Figure out what packages provide these libraries. Download the ClanLib and SDL packages. Try to install these libraries; see the package manager complain again about a library called libHermes.so.1; curse the package manager. Repeat steps 3 and 4 for the Hermes package, and install it. Finally, install pingus. Similar scenarios can be found for package removal, since a package cannot be uninstalled until any and all packages that depend on it are removed first. Package upgrade is similar to installation; it is not enough to simply get the newest version and install. The newer package might have different dependencies from the old one, requiring different or new versions of certain packages
Please read the rant a bit more carefully. I did not say that I wanted all distributions to be alike. In fact, I mention this issue specifically:
All I'm saying is that there is no advantage to having incompatable packaging systems. A unified packaging specification would allow developers of programs to create one package and have it install across distributions; it wouldn't force those distributions to change anything (except to conform to a standard filesystem layout).
(I suspect that the new Yo-Yo effect makes it harder to moderate idiots like me!)
"A microprocessor... is a terrible thing to waste." --
"A microprocessor... is a terrible thing to waste." --
GeneralEmergency
*grins*
http://gabrielcain.com/