An RPM Port Of APT 197
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."
Ah, finally... (Score:1)
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.
Re:Apt IS great, now if we could USE it. (Score:1)
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.Re:parent poster is RACIST (Score:1)
Timecop?
Silly mofo. I'm gonna beatchyo ass.
Re:too complicated... (Score:2)
--
Re:too complicated... (Score:1)
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.
Re:Great (Score:2)
Overall, though, the dependency problem is minor, but broken packages DO sneak into unstable and stable (!!!!!) every now and then.
Re:Related Kuro5hin Rant (Score:1)
exactly...that's the point! (Score:1)
Re:too complicated... (Score:1)
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.
Re:Apt is not enough (Score:1)
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.
Related Kuro5hin Rant (Score:2)
I (a while back, admittedly) posted an article [kuro5hin.org] 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.
Re:Argh (Score:1)
http://www.linuxfromscratch.org [linuxfromscratch.org]
PS, This is like roll-your-own, using SysVinit (aka RH rc script), small and clean like Slackware, very good combination.
Re:The problem is in the dependency database (Score:2)
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.
Re:I (and many brazilians) don't like the idea. (Score:1)
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
Re:The problem is in the dependency database (Score:1)
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.
Re:make install? (Score:2)
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.
Re:Downtime? (Score:1)
Re:The problem is in the dependency database (Score:3)
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.
Re:Apt IS great, now if we could USE it. (Score:1)
Re:The problem is in the dependency database (Score:2)
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.
Re:Perhaps one day Linux will become useful like B (Score:1)
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...
Does this potentially kill Debian? (Score:5)
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.
Re:apt & lsb (Score:1)
Storm Linux (Score:1)
If you're looking for an easier-to-use debian, I'd recommend Storm.
Re:Argh (Score:1)
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.
If they is anything I want the most... (Score:1)
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.
a blow to debian (Score:2)
Re:I (and many brazilians) don't like the idea. (Score:1)
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?
Argh (Score:2)
Re:too complicated... (Score:1)
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.
Re:Perhaps one day Linux will become useful like B (Score:1)
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.
Apt scaled (Score:3)
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
Re:Perhaps one day Linux will become useful like B (Score:1)
Thats the kinda FUD that steers me away.
Re:Apt IS great, now if we could USE it. (Score:2)
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.
Re:It's all about... (Score:2)
-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.
Mandrake does it already with RpmDrake/urpmi (Score:1)
The only thing thats missing is "dist -update", as that's how they make their money
--
Full plate and packing steel! -Minsc
Re:Fueling the war even further... (Score:1)
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.
Re:apt & lsb (Score:2)
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.
Re:Does this potentially kill Debian? (Score:2)
Re:apt & lsb (Score:3)
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 [stormix.com]? 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.
Re:What...Where..WHY... (Score:1)
Hows that for a low UID?
Re:apt & lsb (Score:1)
Deo
Terradot.org [terradot.org]: Growing Awareness
Re:I Dos'ed Slashdot in protest! (Score:1)
Your post helps show why we need moderation.
Re:make install? (Score:1)
Re:too complicated... (Score:1)
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!!!!
Re:The problem is in the dependency database (Score:2)
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!
Re:It's all about... (Score:3)
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'?
Re:This is great for Linux... (Score:2)
Re:This is great for Linux... (Score:2)
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
But this doesn't solve any of the real problems! (Score:3)
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
this is good (Score:2)
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!
What good is it to have different distributions... (Score:2)
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.
Re:The problem is in the dependency database (Score:3)
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)
Re:The problem is in the dependency database (Score:2)
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.
Re:This is great for Linux... (Score:2)
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.
Re:Thoughts on package management (Score:2)
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
--
Re:Does this potentially kill Debian? (Score:2)
The beauty of Debian is how cleanly it is packaged - not just apt. It is a distribution done by system administrators largely for themselves. It is not going anywhere. As long as it still benefits the package maintainers, Debian will thrive.
Other distributions are packaged for profit. That brings in other motives. Distributions will sell themselves as packaging things more rapidly or packaging things for 586 instead of 386 (like Mandrake). Distributions will fund a lot of development and sell themselves as containing the latest compiler (Redhat). Debian is packaged because it works the way a bunch of system administrators think Free Software should work.
And there will always be plenty of room for that. If you and/or others go running to Redhat once apt is working well with rpm, so be it. Debian will continue to thrive because it cannot die. It can't lose its funding because it hardly has any. Debian works because volunteers make it work (and a very small but growing number of paid developers).
This doesn't affect Debian at all (Score:2)
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.
Re:Does this potentially kill Debian? (Score:2)
Right, but Debian (and Linux in general) depends almost entirely upon the donated time of its volunteers. The more volunteers, the larger the pool of donated time. Apt draws volunteers to Debian because it makes Debian better than most of the other distros. But if the value of Debian is replicated somewhere else, w/out all of the inconveniences of Debian, then your volunteer force diminishes. (Example inconvenience: almost no support from vendors who will only certify their products with RedHat.)
I'm sure the answer to this is that Debian will continue to exist if only one developer is working on it. But one developer can't do the entire thing, can't keep up with every package upgrade, bug list, new package, etc. There is a critical mass that is required to keep the distribution going. (There is a critical mass that is required to keep Linux going.) Does apt-rpm have the potential to lower the volunteer force below the critical mass? Clearly you think not, and you've given one example of why apt is not the only thing that makes debian great. Any more?
Re:apt & lsb (Score:2)
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. [linux-mandrake.com]
Re:This is great for Linux... (Score:2)
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.
Re:make install? (Score:2)
For example, suppose a program relies on a specific version of diff. What file should it look for?
Re:Apt IS great, now if we could USE it. (Score:2)
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.
Re:make install? (Score:2)
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.
Re:you too? (Score:2)
Can anybody tell me what problems in specific they had upgrading to 7.0, or is this just anti-RH FUD?
Re:Apt IS great, now if we could USE it. (Score:2)
Ok I must be wierd. I actually like dselect.
I guess it's an acquired taste like Guinness.
Re:Does this potentially kill Debian? (Score:5)
Here begins some serious speculation.
1) Apt on other distros will not work. Apt depends on package dependencies being done very cleanly, and this is simply not true in any other distro to the same extent that it is in Debian. The other distros need not only apt, but they also need a packaging policy.
2) Debian is self-supporting. People who find Debian and enjoy it because it is done for the benefit of its volunteers generically enjoy the distro. This is not going away any time soon. One might argue that Debian is competitive with develops with other distros, but I don't think that is true. Other distros pay their supporters, and Debian is still a distro of volunteers.
3) Debian developers are among the most stringent Free Software supporters. They are in it to create the best Free Software distribution possible. Many people think they already have it. There are literally no challengers - distributions with strict Free Software guidelines.
4) Debian is an active development environment. Apt is just one example - it is not a killer app in and of itself. Debian initscripts are better (IMHO) than those of the other distros I have checked. Debian security is up there as well.
5) Debian has more packages than Redhat or Mandrake or SuSe. They have these packages in their 'official' distribution - not available packaged by someone else at rpmfind.
Basically, I think the care in packaging of Debian is about 18+ months ahead of anyone else. And for that reason I can see no reason to even consider another distribution for my boxes.
We use Redhat at work. I get called a weenie for supporting Debian. But administering my Debian boxes takes 1/10th the time it takes me to administer my Redhat boxes. And that is the only reason I need to stay with Debian. YMMV.
Re:a blow to debian (Score:2)
The problem is in the dependency database (Score:5)
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.
This is a next step (Score:3)
Most of it comes from thorough policy and packaging guidelines from The Debian Documentation Project [debian.org]. 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.
Re:Argh (Score:2)
www.linuxfromscratch.org (Score:2)
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.
Re:Does this potentially kill Debian? (Score:2)
It won't. Linux-wise, I've used Debian, Red Hat, and Mandrake. Debian just seems a lot cleaner to me. Everything seems to be organized better. There's an overall impression of design, the defaults are well-chosen, and the dependencies are intelligent.
-RickHunter
Re:Not Fud. (Score:2)
Most of the time I ditch the graphical installer on RH and just install from text mode. 'Tis easy, quick, and painless.
Apt is not enough (Score:5)
- 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'm not so sure. (Score:2)
Re:Apt IS great, now if we could USE it. (Score:2)
Do you have any coredumps? I haven't managed to catch it in the act yet..
Daniel
Alfredo Kojima (Score:4)
* 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.
Conversion (Score:2)
Escape from DLL Hell! [hardcorelinux.com]: The ultimate Package Manager Howto
Re:Apt IS great, now if we could USE it. (Score:2)
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.
Re:I (and many brazilians) don't like the idea. (Score:2)
Granted that apt worked and works great for .deb, but it didn't for .rpm and now it does. Don't you consider that innovation?
As for changing from .rpm to .deb, it's a hell of a change. Do you think they want to dump all they've done with .rpm and switch to .deb?
And, personally, being a programmer, I like .rpm more than .deb. Why? Because of .src.rpm.
apt & lsb (Score:5)
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.
Re:Argh (Score:2)
When so many packages have so many compile time options (Apache, PHP, Perl, etc) and with just about every distro being so lame with respect to the filesystem standard, why bother with 'em? God forbid you have library problems with RH, and god forbid you have to use dselect.
Yeah, I could probably at least try the different packages, submit bug requests, etc., but my time is better spent rolling my own at this point.
(Actually, I'd probably get slack, but I'm so used to the RH style init-scripts. Yeah, lame excuse)
Not even that tough. (Score:2)
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.
apt (Score:2)
Perhaps one day Linux will become useful like BSD (Score:2)
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.
Re:apt & lsb (Score:3)
Apt IS great, now if we could USE it. (Score:5)
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.
I hope the other distros get it right... (Score:3)
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.
Re:Apt IS great, now if we could USE it. (Score:3)
Re:This is great for Linux... (Score:2)
Re:make install? (Score:2)
Re:The problem is in the dependency database (Score:2)
I build rpms for *everything* I install, if it's not already available as rpm, because it takes only slightly more time than ./configure; make; make install, and having the database is so convenient.
Re:The problem is in the dependency database (Score:2)
"If ignorance is bliss, may I never be happy.
make install? (Score:2)
---
Re:Apt scaled (Score:2)
Why are we speaking of Mandrake here? You can download individual mandrake RPMs from their usual ftp mirrors, or from rpmfind.net.
Re:apt & lsb (Score:2)
- Package formats
- Package database systems
- Dependency database systems
- Dependency resolution (i.e., apt-get-*)
- Creation of installation packages when building from tar balls
- Graphical front ends to distribution installations
- Graphical front ends to basic configuration tasks, such as configuring X beyond default parameters, or configuring the network, or even hardening systems a'la Bastille?
Yeah, I know... RH has its "technical capital" invested in RPM, while Debian has its "technical capital" invested in deb/apt. And what I am asking about is non-trivial. However, if there were some interest, maybe this is a worthwhile project to undertake.Re:Apt IS great, now if we could USE it. (Score:2)
treke
Re:apt & lsb (Score:2)
It appears that your underlying motivation for detracting from linux is that you hate linux's growing popularity
because it overwhelms BeOS' popularity.
>>>>>>>>>>>>>>>
Really. That would explain why BeOS never occurs anywhere in my post. I do use BeOS, and no I don't resent Linux for its popularity. I think it could do some things differently, but if it ever becomes better than BeOS (from my POV of course) then I'd have no problems switching.
First of all, FreeBSD is basicly a distribution like Debian is, and like Redhat is. The only difference is that FreeBSD has its own kernel as well.
>>>>>>>>
No. FreeBSD is not a distribution, it is an OS. The FreeBSD guys not only work on the kernel, but in userland as well. This compares to the Linux distro guys (sorry, I haven't tried Debian so I don't know if that applies to them) where the most work they do in userland is to mess up some packages like KDE2 and GNOME to include ugly icons and fake dependencies. Compare this to FreeBSD and its "architectured" design, and you see my point. Examples: FreeBSD has a method for upgrading the system that whoops everything (except maybe Debian) CVSup all the way. And it does it with userland tools too, courtesy of the organized nature of the project. If you take a look at the command line tools, you'll notice that they all work like CVS (or CVS works like the BSD tools) secondary commads don't have a -, there is only one format for commands (not -h and --help) and parameters are much more standardized.
As far as your opinion that FreeBSD feels slick, that is a totally subjective, not to mention unsubstantiated, claim, that I will call it a frivolous comparison made to make linux look bad.
>>>>>>>>>>>>.
Yes, that's my whole purpose in life, to make Linux look bad. Good god are you one of those conspiracy theorists? Yes, JLG has hired me to disparage Linux as much as I can and to open up the way for Be to become the next windows. Slickness is not subjective. FreeBSD has polish. It shows in the config scripts, directory layout, package system, config programs, etc. Hell, even the kernel config file is really clean. Its obvious that Slackware are Debian are just more slick than, say, RedHat. Same thing for FreeBSD.
Nvidia, ReiserFS, etc, although they aren't default in linux distributions, they are none-the-less fully compatable with 99.9999% of things out there, and if there is an incompatability that hole will most surely be paved over momentarily.
>>>>>>>>>>
Huh? I like ReiserFS and the NVIDIA drivers. I never said they were incompatible. The NVIDIA drivers in particular are why I don't plan to keep BSD. The NVIDIA drivers shouldn't be standard (because its not applicable to all systems). When ReiserFS becomes stable (ie a part of Linux 2.4) then it would be wise for the LSB to adopt it as the standard filesystem. It's not a software incompatiblity thing, but a system thing. A book written for the LSB standard should be 100% applicable to any distro out there that supports that standard. I'm not saying that these should be the ONLY types of distros, the Debians and Slackwares of Linux-land will continue to exist, I'm just saying that a standard should exist. If it is a good, strong, standard, then you get lots of benifits. There is a minimum level of quality assurance. You get software and package compatiblity (I don't have a quad Xeon, I don't have time to compile everything from source. RPMS are so tied to their distros its ridiculous) and user interface compatiblity. You see all these people get mad when commerical software only officially supports RedHat, but if you had an LSB standard, then commerical software could support a much larger range of distros without having to worry about distro-specific issues.
Mr BeOS advocate general, I guess we can call you that, your fanaticism is very apparent. I appreciate your interest in Beos, and hope BeOS succeeds in the way you want it to. But I don't appreciate your niggardly, constant detraction from linux. I think you have ulterior motives. I understand that you, yourself may not have come to terms with these motives, as they appear to be rooted in your emotional synapses.
>>>>>>>>>>
Hey, I think you're trolling? I detract from Linux because I have no interest in being one of those "me to" idiots that do nothing but extoll Linux's virtues. Linux has its problems. You can't ignore that fact. It has its good sides, but we already know about those. The problems are where our attention should be focused. The more people that know and complain about the problems, the more likey it is that they are going to get fixed.
Re:This is great for Linux... (Score:2)
Furthermore, RPM is a *good* packaging format. If you want to bash it, give some examples of problems rather than just FUD.
--