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."
--
Overall, though, the dependency problem is minor, but broken packages DO sneak into unstable and stable (!!!!!) every now and then.
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.
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 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
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.
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
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.
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
Am I the only one who still uses tar to install software?
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
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.
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.
"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!
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'?
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
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
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!
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
> 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.
"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
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.
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.
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
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
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...
Can anybody tell me what problems in specific they had upgrading to 7.0, or is this just anti-RH FUD?
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!
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 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.
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
Most of the time I ditch the graphical installer on RH and just install from text mode. 'Tis easy, quick, and painless.
- 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!
* 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
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.
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.
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 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!
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.
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.
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.
Furthermore, RPM is a *good* packaging format. If you want to bash it, give some examples of problems rather than just FUD.
--