Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Linux Software

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."
This discussion has been archived. No new comments can be posted.

A RPM Port Of APT

Comments Filter:
  • I'm tired of my newly converted Debian friend (ex-RedHatter) mocking me when I have to update an rpm, and end up spending hours on rpmfind.

    This should help keep a bunch of distros even closer... which should be the aim of all of the distributions, while keeping their various specific bonuses (such as Corel being businessish, etc)
    ______
    everyone was born right-handed, only the greatest overcome it.
  • Ok I must be wierd. I actually like dselect.

    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.
  • Lol!

    Timecop?

    Silly mofo. I'm gonna beatchyo ass.
  • tarballs are simple for one machine with one admin. However, when you've got a bunch of machine s that've been maintained by multiple people for years, you start to appreciate package managers really quickly.

    --

  • All of these security issues have been fixed. If you are really concerned about security, subscribe to the slackware-security mailing list at majordomo@slackware.com. Also, most of the fixes go into slackware-current, not /patches. you can check ftp://ftp.slackware.com/pub/slackware/slackware-cu rrent/ChangeLog.txt if you wanna know what has been changed since the last release. To fix a security problem, just download the package from slackware-current, and run 'upgradepkg packagename.tgz', and all is done for you.

    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.

  • Four days ago when I was trying to install something that depended on GTK, I discovered a broken dependency that exists in both the stable and unstable dists. Debian's idea of QA has cost me several reinstalls over the years because sometimes the package managers don't thoroughly check for these conflicts.

    Overall, though, the dependency problem is minor, but broken packages DO sneak into unstable and stable (!!!!!) every now and then.

  • hey, you should look into the berlin consortium. I am currently thinking of programming some stuff for them, it looks like it has the potential to at least unify X with the many window managers, and make it a whole lot faster. I think we should work towards a more unified linux, choice is good, but when you are choosing between many incompatible platforms that all have benefits and weaknesses, it makes no sense. I like the berlin consortiums ideas alot (no more X!!!), if only we saw this kind of thing in other areas as well.
  • I knew a guy who call himself Mr. I-Am-Elite-and-Edit-Everything-By-Hand-in-Linux.. This kind of people really have trait. I should've challenged him to write assembly code instead. Being an 31337 == being a time waster. I think if he wants to edit config for his life, he'd better go back to where he belongs editing WinNT registry.

    Another thing is, security. For example, take a look at
    ftp://ftp.slackware.com/pub/slackware/slackware-7. 1/patches/ [slackware.com]

    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 /etc/hosts.equiv that contains "localhost" line with rlogin service turned on by default (this was in my friend's Slackware 7.0 system). Okay, this is just by default and can be prevented, but what if the user does not know Linux at all and his machine got hacked?

    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.
  • by Anonymous Coward
    I used Debian from 0.8 or so through 2.0. Frankly Debian sucks. Talk is cheap. Backing up that talk is a hell of a lot more difficult. If you ever tried to use dselect you would know what I'm talking about. Oh, and the bugs -- Debian is by far the most buggy of any Linux distribution. Maybe a better way to put that is that Debian is the most variable of all distributions. Some stuff is less buggier than others. But most of it is packaged and maintained very amateurishly. It may be that the basic base systems is about average with respect to bugs. But once you stray from the minimal you will find so many buggy crude ".deb" packages that you will be pulling your hair out.

    The annoying "dselect" dependency handling will make you howl in pain. For example, it will "suggest" unneeded bullshit when you select a package. But the "suggestion" is more like a hammer over the head and you have to go and manually remove the additional cruft from its installation list. And that is not all. Many of the so called dependencies are not even real dependencies. For example, you might select a simple text mode package, but Debian will force you to install the X Window System front end for the package and all the X libs needed for that front end. But all you wanted was the simple text mode stuff. Tough luck, you have to manually f*ck around to remove all the unwanted BS. Debian is not so hot as its advocates claim. I base my opinion on several years of experience and not some starry eyed dreaming.

  • I (a while back, admittedly) posted an article [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.

  • Bough of you, please check out LFS... you may find it very interesting for just this reason;

    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.
  • 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.

  • Although I think it is a duplicate effort (look at rpmfind), I like the idea.

    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

  • Until then, based on my past experiences with Redhat's RPM, I won't at all be interested in a fancy packaging system


    Then don't use a fancy packaging system, but a simple one. Indeed all this fancy stuff is a waste since it'll break sooner or later anyway.


    Simple no-nonsense packaging systems such as those from Slackware of *BSD.

  • If a package installer checked what was actually installed, instead of what a database claims is installed, then I would be more interested in it.

  • The current hearsay is that Exodus made a typo in a router config.
  • by Fluffy the Cat ( 29157 ) on Saturday December 02, 2000 @05:20PM (#586267) Homepage
    It's possible to create a deb package for most apps with about 30 seconds of extra effort (dump standard files into top of source tree, edit to change version name and add any vital dependencies, type fakeroot dpkg-buildpackage and wait). You'll end up with a package that can be dumped into a local apt archive and distributed site wide. I prefer this to compiling stuff by hand and installing because it becomes a real pain to keep track of which versions are installed on which systems I look after. Adding local patches is even easier - apt-get source packagename, apply patches, add an extra entry to the changelog and change the version number so that mine won't be overwritten. Rebuild and I now have a package that's identical to the one produced for my distribution except with the changes that I desire.

    Sure, this isn't exactly what you want. A system that could do this sort of thing automatically (maybe some sort of wrapper around install(1)) would make life easier still, but with the current situation the time a decent packaging system saves me easily outweighs the extra time taken to play by the packaging system's rules when installing stuff.
  • Same with me for 2.2, I didn't even touch dselect after the install and then the very next day I just dist-upgraded to woody and since then I think I've only gone into dselect once to maybe try to learn how to use the damn thing but after doing a few things I just quit because I thought I would hose the system with the stuff I did. Since then I've never tried it again because I don't need to thanks to apt.
  • 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.

  • So you've just described apt-get, but you have to compile everything. How easy is it to remove packages? I allways hear people tooting the ports tree as being something revelutionary, yet I still haven't heard anything unique about it. Your claim that Debian copied BSD is kind of unjustified. At most you can say they were motivated by it. Did apache copy ncsa? At least with apt, you can simply apt-get update. How easy is it to update the ports tree?
    So its "tastefull" to use a BSD kernel in Debian? The kernel was "patched" into their userspace? How often should a system administrator have to update her kernel? If it's some where like once a day then I would understand why CVS is more convenient...
    Please get of your holy stool...
  • As a Debian user, this has me wondering what could happen if say RedHat suddenly adopts this. I find myself torn between the unbelievable convenience that apt gives me, and the inconvenience because Debian is not being RedHat, and so much of Linux has a RedHat focus.

    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.

  • Have you tried Debian? Of all Linux distributions it's the most consistant, and it's the only one I know of where failing to follow existing convention is considered a serious bug unless there's a damn good reason for it. See the Debian policy manual [debian.org] for more information.
  • I'm pretty comfortable with debian myself, but I was recently looking around for a more user friendly version that I could recommend to newbies. So I tried Storm Linux [stormix.com], and I have to say it's quite nice. It's basically Debian Potato with an easy graphical installer and some custom Storm packages, among which are helix gnome and a nice gtk-based front end to APT.

    If you're looking for an easier-to-use debian, I'd recommend Storm.

  • 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.

    What is this "either/or" shit? There are times to use apt or rpm, and their are times to compile things from scratch. At this point, I use apt 70% of the time, and tarballs the rest. On RPM boxes, I probably use rpm only 40% of the time, and tarballs the rest, because it's nowhere near as easy to use rpms as it is to use apt. I use dselect only when I absolutely have to, like during an install.

    Each method has some things to recommend it, and there isn't a reason to use one or the other exclusively, as far as I am concerned.


  • It's more standards in the way we do things. Installing RPMs can be a pain sometimes but with people taking steps like this I think it's great. APT is going to make it easier for people to install and update now there distributions of Linux now. Isn't that great!? I would like to go to an site and just download something install it without picking what distributions and version I'm using or use an update program to get the next version of GIMP. If APT is something I see in the next Mandrake,Redhat or any distro I'll be happy, because long as someone is taking that step. If you ask me, I'm up for a change... I don't care if RedHat drop RPMs and started using DEBs with APT. Long as it help get Linux on more Desktop and help get more apps.
  • 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
  • With one patch limit. And the generation of .deb files is not done from a central script. You might like that and I am quite sure the creators of dpkg also do. For me, it's awful. It's just an opinion.

    Now, for your claim it won't work, it's unjustified. Let them at least give it a try.

    Dependencies problem!? Isn't that EXACTLY was apt is supposed to do? Solve those problems? Your arguments are not making sense to me.

    And last, the dependencies have to be well-thought from the vendor point of view. If Conectiva proposed using apt in their next release, they have to make it work on their repositories. If you wish to add apt to another distribution (say, you want to use original apt on Slackware or even Corel) or you want to use another source of packages, it's your own risk. They can't possibly be considered responsible for someone else's packages. Nor can Debian be considered responsible for use of apt on Slackware or Corel (that uses .debs) or use of third party packages.

    Or can they?

  • Am I the only one who still uses tar to install software?
  • ...or you'd have Slackware's packages.

    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. :-P
  • Too bad. Then why the comment about 'getting off your holy stool', if you admit the BSD design is cleaner, and you didn't give BSD a chance to shine?
    I made the remark because the guy was zealous. Just look at the title of his message.

    Do they have kernel modules in any of the *BSDs? Its really a usefull feature for higher level kernel programing. Its pretty nice to be able to dynamically change what hardware the kernel supports as well.
  • by patreides ( 210724 ) on Saturday December 02, 2000 @03:12PM (#586281)
    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 :-)
  • a good os vs linux
    Thats the kinda FUD that steers me away.
  • The Red Hat approach of 'install 900Mbyte of crap' is better.
    Debian has had something like this for a while (though perhaps it's not well advertised or fully implemented). There are virtual packages named task-* that require all the necessary files to perform some task, so if you do apt-get install task-science you will get a fairly appropriate set of packages installed for doing scientific work. There's quite a bit of granularity to this too, since there can be task packages for developing in certain languages, foreign languages tasks, etc., as well as more general configurations.

    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.

  • When I first installed Mandrake, I thought the automatic update was cool and awesome, but that lasted about a week. My two biggest complaints are (and this applies to RedHat since they now offer similar services):

    -As other people mentioned, it is not just downloading a package and installing it, it is also about having high quality packages with high quality dependency checking. Mandrake/RedHat routinely do not have an rpm I want, and after only a short time of installing packages that I get on rpmfind, my dependencies are so screwed up I need to do a clean install (as in reformat my system partition) to get things working.

    -You only have access to the updates on your current version. For example, if you have Mandrake 6.1 and Mandrake 6.2 comes out with a new version of emacs, then the automatic update tool doesn't pick it up. (This is what happened to me, and I haven't stuck with Mandrake long enough to see if it changed.)

    The biggest problem with the rpm distros as opposed to Debian, is the update process is not a "smooth". With Debian, you can update periodically and end up with updating just one package to get the "official next version". I would LOVE to have that smoothness with RedHat or Mandrake, especially for the security fixes.

    With the commercial distros, they want to get you to either buy the next version or subscribe. I have no problem with paying for a subscription that is reasonably priced for my work machine (where RedHat is the most useful distro), but their subscription service is outrageously priced for businesses who just want to click a button and download the latest packages. I like a lot of RedHat's plans and directions, but when I look at their quality and price, I don't think they really have it together.

  • Demo here [linux-mandrake.com]
    The only thing thats missing is "dist -update", as that's how they make their money :)
    --
    Full plate and packing steel! -Minsc
  • Why is it great to compile everything if you are on something other than x86? From what I've heard, some of the slower boxes (m68k, for example) are real pains to compile large programs on. You also don't have any assurance that the code even compiles on your platform. With Debian compiling for Alpha, ARM, Sparc, M68K and PowerPC, there's little difference between i386 and any other platform.

    As for having the source on hand ~/Program_Source comes to over 500 MB on my system, and is usually one of the first places to look for needed space. I'm glad I don't have to carry anywhere near the source for every program on my system. I can apt-get source (or buy a CD) if I need the code, and delete it when I get done.
  • ReiserFS is a bit faster than the BSD filesystem. (Though I haven't tried softupdates yet.)

    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:

    • bare sequential read/write
    • parallel reads/writes
    • random access
    • operations on metadata such as creating/removing directories or large amounts of files

    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.

  • I said:
    I find myself torn between the unbelievable convenience that apt gives me, and the inconvenience because Debian is not being RedHat, and so much of Linux has a RedHat focus.
    My apologies. I meant to say that I find myself torn between the convenience of apt and the inconvenience because Debian is not RedHat, and so much of the Linux world (i.e. corporate sponsorship, product support, etc) has a RedHat focus.
  • by ArtDent ( 83554 ) on Sunday December 03, 2000 @12:02AM (#586289)

    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.

  • Hah.

    Hows that for a low UID?
  • Heh, I know you're just trolling, so its probably on purpose, but I couldn't help but get a chuckle from seeing the phrase, "rage with an identidy you coward," from someone going by the name "barneyfoo." Thanks for the chuckle; troll on, as you keep the bites chomping well.

    Deo

    Terradot.org [terradot.org]: Growing Awareness
  • Good for you.

    Your post helps show why we need moderation. :-P
  • So what's your suggestion then? How do you propose that a package installer determine what was "actually installed", without resorting to the use of magic?
  • Yes you are right. The only thing that comes close to Slackware for being totally 31337 is Debian of course. This was proven to me earlier in the week when I installed Mandrake 7.2 on a new system equipped with a Mylex AcceleRAID 170 card in 18 minutes.

    Fear not!! I was in no danger of being sucked into the lameness of Mandrake. Our Debian surfin' sysadmin came along, wiped Mandrake, and then spent the rest of the week being 31337 with the Debian installer that didn't work and didn't recognise the Mylex card.

    He got it in the end...after spending about 3 days reading DejaNews and formatting specialised boot floppies with specialised kernels on them. Damn it was an 31337 experience!!! I felt like a fool for using Mandrake all this time that completed the whole installation in 18 minutes. Never, never again!!!!!

    31337 Debian and Slackware all the way!!!!
  • "Inevitably, the database will get out of sync
    the moment you have to compile something from source because no .deb or .rpm file is available right then, or..."

    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!

  • by oingoboingo ( 179159 ) on Saturday December 02, 2000 @05:47PM (#586298)
    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.
  • The problem with those packaging formats is when you install a new package, for example webalizer, that requires newer version of libraries, for example libpng and zlib, and you cannot found the RPM files for your distribution (for example Redhat 5.2, Suse 5.1, etc.etc), so you install the new packages from a tar file of converting the RPM to a CPIO file.

    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

  • by Jakdaw ( 103263 ) on Saturday December 02, 2000 @03:20PM (#586307)
    This editorial doesn't really address the issues and problems with packaging and distribution of software with current linux distributions.

    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 as it will hopefully end the rpm is beter than dpkg or dpkg is better than rpm. Hopefully it will be adopted by other vendors other than Conectiva.

    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 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.

  • > 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)
  • 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.

  • Of course, it's almost certain RedHat would oppose any attempt to get rid of it's inferior RPM format.

    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."

    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
    --
    .|` Clouds cross the black moonlight,
  • 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.

    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).
  • I recently gave Debian 2.2 a try and it didn't make it. The packaging system might be better than rpm, but by itself it's not enough to make Debian better for me.

    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 works because volunteers make it work (and a very small but growing number of paid developers).

    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?

  • 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-).

    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]

  • 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.

  • 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.
  • 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.
  • What? I've been using 7.0 since it was, well, 6.9.5, and I upgraded from 6.2->6.9.5->7.0 on two machines. Perfectly. No problems whatsoever.

    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.

  • by blakestah ( 91866 ) <blakestah@gmail.com> on Saturday December 02, 2000 @07:55PM (#586353) Homepage
    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.

    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.
  • No, it will simply motivate the Debian developers to advance other aspects of Debian in order to maintain its status as the technological leader of Linux distributions.
  • by Skapare ( 16644 ) on Saturday December 02, 2000 @03:40PM (#586358) Homepage

    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.

  • by blakestah ( 91866 ) <blakestah@gmail.com> on Saturday December 02, 2000 @04:09PM (#586362) Homepage
    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 [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.
  • Eventually, you get to a point where you have changed enough stuff that even the simplest RPM doesn't want to work. Things may be different for apt. Not sure. That's why, for me, it's 'either/or'.

  • 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.

  • 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
  • Me too (RH since 5.0 on a cd lent from a friend was my first intro to Linux and saved me from the evil NT!). Debian 2.1 (haven't tried 2.2) wasn't all that hard to install, except for its twenty gazillion questions phrase.

    Most of the time I ditch the graphical installer on RH and just install from text mode. 'Tis easy, quick, and painless.

  • by Nicopa ( 87617 ) <nico DOT lichtmaier AT gmail DOT com> on Saturday December 02, 2000 @08:01PM (#586378)
    APT is just part of the thing. Debian has been great and smoothly updatable for many years... before apt was created. I'll list the things (from Debian) that RedHat needs to make this work:
    • 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.
  • occasionally segfaults, but usually just upon exiting

    Do you have any coredumps? I haven't managed to catch it in the act yet..

    Daniel
  • by update() ( 217397 ) on Saturday December 02, 2000 @04:14PM (#586386) Homepage
    Alfredo Kojima was my nominee for "Unsung Hero" in last year's Slashdot awards and his involvement in this project makes me even more likely to renominate him this year.* I'm not sure why he and WindowMaker get none of the drooling adoration that Slashdot lavishes on other desktop project developers but he and Dan Pascu and their team make what I think is the stablest, fastest and best looking desktop around.

    * 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 [kitenet.net] . 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 [uiuc.edu] and GNU STOW [gnu.org], 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! [hardcorelinux.com]: The ultimate Package Manager Howto
  • 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.

  • They are reinventing the wheel? By adding code to apt that there wasn't there before? How come?

    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.

  • by barneyfoo ( 80862 ) on Saturday December 02, 2000 @02:33PM (#586392)
    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.

  • Nope. There's some of us left. I'm also getting fed up with "ooh, I like SlackPotatoHat distro" and will likely be rolling my own in the near future.

    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)
  • 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.
  • by iomud ( 241310 )
    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.

  • by be-fan ( 61476 ) on Saturday December 02, 2000 @02:37PM (#586413)
    Apparantly the LSB has no scope whatsoever. I seriously think they should grow some balls and create a standard. It's not like everyone has to follow the standard, but as long as one exists and is effectivly promoted, most distros will support it. And those that don't, don't. That's free software. I have been trying out FreeBSD 4.2 lately, and I have to say it is quite slick. Linux, even distros like Slackware, feels cobbled together. However, with FreeBSD, there is so much consistancy, so much thoughtful design, and actual CONVENTIONS, that I weep with happiness. Problematically though, the NVIDIA drivers are a lot faster than the Xfree86 ones (even at 2D they are about 30-50% faster) and ReiserFS is a bit faster than the BSD filesystem. (Though I haven't tried softupdates yet.) If I wasn't obsessed with graphics performance, it would definately become my next *NIX.
  • by rMortyH ( 40227 ) on Saturday December 02, 2000 @02:51PM (#586417)
    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.

  • by Tuzanor ( 125152 ) on Saturday December 02, 2000 @02:52PM (#586420) Homepage
    When corel ripped of Debian and i first tried apt get with it i kept getting a million errors when i was getting them off the main debian site. I emailed corel about this and they said that they made some "enhancements" .debs to make it easier and to use any corel site(of which DEFINATELY don't have as many packages as ftp.debian.org).

    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.

  • by SquadBoy ( 167263 ) on Saturday December 02, 2000 @02:56PM (#586424) Homepage Journal
    Try Debian 2.2 you do not have to touch dselect to do a install anymore it is really sweet
  • Last I checked, the Debian source packages could only include one source tarball and one patch. src.rpm packages can include several source tarballs and several patches.

  • 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.
  • Creating RPM files is pathetically easy & takes about 2 minutes after you learn to do it. After building a few, you can copy & edit a spec file for a new project trivially.

    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.

  • I think kinstall [freshmeat.net] is what you're looking for, if you want an install(1) wrapper.

    "If ignorance is bliss, may I never be happy.
  • Perhaps "make install" could update the database?
    ---
  • 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

    Why are we speaking of Mandrake here? You can download individual mandrake RPMs from their usual ftp mirrors, or from rpmfind.net.
  • The main question I would have is why hasn't there been a move a-foot to standardize the following for Linux across the board:
    • 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.
  • Yes dselect is a pain in the ass, that's what kept me from switching to debian untill RH7 pushed me. Since then I havent had a need to use dselect yet. Between plain dpkg and apt everything works find. I think dselect itself is on it's way out the door, probably to be replaced by tools like gnome-apt and console-apt.
    treke
  • Your comments sound uninformed and rash.

    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.
  • Did you read the article at all? This doesn't have anything to do with getting rid of RPM. It's a tool that exists on top of the package mananger and deals with things (dependency resolution, finding mirrors) that the package manger itself doesn't.

    Furthermore, RPM is a *good* packaging format. If you want to bash it, give some examples of problems rather than just FUD.

    --

"I am, therefore I am." -- Akira

Working...