

RPM Package Manager 180
Things have changed quite a bit since we last posted about the state of Linux Package Management. Over the few months ago, we saw the Connectiva release, which was a RPM front-end to apt-get [?] . Now, for those of you running RH6.x, there are a new program called Aduva Manager. It's kinda like using apt-get update/apt-get dist-upgrade, but checks dependecies and such for RH6.x based systems. They've got screenshots as well as a FAQ/download site. It's designed more for new users, but it looks like a step in the right direction for RPM.
sounds like up2date (Score:1)
Package Managers (Score:3)
How else are you going to be able to troubleshoot or modify any tweaks/perks/or problems that may occur.
Or take for example the debian debacle of a couple weeks ago. I did an upgrade then an install of a couple things only to find out that X was going to crap the bed on me... If I had been less lazy (yes I know that goes against EVERY netadmin's fibre) and had compiled the programs myself I could have saved a couple hours of time in the long run.
But as far as getting *nix out to the masses I applaud RH and Debian for attempting to ease the installation of software for new users.
Yet another reason for... (Score:1)
Could someone enlighten me please... (Score:1)
I suppose some will argue that it is because RPM is the 'standard', but the fact is that the standard is pretty much whatever Red Hat decrees it to be.
I just don't understand why Red Hat are continuing to use an arguably outdated system.
KTB:Lover, Poet, Artiste, Aesthete, Programmer.
Isn't freshmeat supposed to do this? (Score:2)
--
I'm so sick of... (Score:3)
Dept of Redund Dept (Score:1)
--
MailOne [openone.com]
It's about bloody time (Score:1)
"Titanic was 3hr and 17min long. They could have lost 3hr and 17min from that."
Re:Package Managers (Score:2)
Re:sounds like up2date (Score:1)
* kernel upgrade - not an RPM upgrade, but entire compilation - with 2 clicks
* dependecy problem - no more. Just upgrade or install - without depenedency headache
* Upgrade entire trees in single click - want to upgrade all your development enviroment? select the branch - and click "upgrade now"
* Hardware support - newer driver comes out? you couldn't install driver or didn't find it? the Manager will do this for you.
* 1 place to download your software - no need to look for RPM's - the program is connected to their server and download what you want from there - with support to broken connection and proxies.
* Built in search engine for RPM's - no need to guess RPM names
* Completely depend from your Desktop enviroment/Winidow manager - whatever you run KDE/GNOME/Enlightment/twm/fvwm/you-name-it - it doesn't need anything
* Its totally free and soon the source will be out..
Now - can you compare those features to any other package management or other solutions available for Linux?
Re:It's about bloody time (Score:1)
The shifting sands of Linux (Score:3)
There is a lot of excitement in the Linux community about getting the latest distribution of (Debian/RedHat/SuSE/Slackware/whatever). This excitement oftentimes results in neglect of older, oftentimes more stable releases of Linux systems.
To RedHat's credit, RedHat still supports releases as far back as RH5.2, in the sense they still releases security upgrades for RH5.2. About a year ago, RedHat silently stopped releasing security upgrades for RH4.2. Since I still run a RH5.2 server (too far away and too mission-critical for me to conveniently upgrade), I dread the day no more security patches are made available for RH5.2.
I know that the people at Linux Weekly News [lwn.net] have been making somewhat of a stink over the fact that Debian announced that they would not make available security patches for 2.1 bugs immediately after releasing Debian 2.2.
Anyway, the point being: The "latest and greatest" is not always the best solution.
- Sam
Recursive? (Score:1)
Re:sounds like up2date (Score:1)
Re:all linux users are criminals (Score:2)
Re:Package Managers (Score:2)
and generally depending on where you get the source from, there seems to be more documentation (README's, INSTALL, what have you) to help you out with.
Yes, I wholeheartedly agree with you that the debian developers who forget more on a daily basis than I will ever learn about their own products have a much better understanding of the tweaks/peeks of the OS and therefore will be able to "fix" any problems long before the majority would even figure out that there WAS a problem.
Re:Dept of Redund Dept (Score:1)
Re:Dept of Redund Dept (Score:1)
--
Re:It's about bloody time (Score:2)
Re:all linux users are criminals (Score:2)
* Underline appropriate option. Multiple options may be valid.
Re:The shifting sands of Linux (Score:1)
What's ironic is that RedHat's up2date service doesn't support RH 7 either (At least, there is no rhl-7.0 directory under ftp://ftp.redhat.com/pub/up2date [redhat.com] ).
The Two Cultures once again (Score:2)
Besides, anybody who says that compiling their own source automatically makes them better understand their machine must not ever execute those "make install" scripts. If an automated process puts 100 files across 12 directories on your machine, and you tell me you can keep track of them all in your head for 100 software packages, I don't believe you.
Hey,autoslack ,anyone? (Score:1)
in all the way that most distro is adopting what apt-get doing@
DEBIAN ROCKS
Hierarchical package display (Score:2)
I like xrpm, which gives a flat view of installed packages or rpms in a directory. A long list, but no hiding in odd mislabeled corners.
Unfortunately, my RH 6.2 has 'aged' too much. I'm seeing too many things that pretty much require me to turn it into RH 7 with prerequisites, so I may as well take the faster route. Then get the updates on, etc.
RPM is handy for a user, as opposed to a developer. Though I try to understand more of the nuts and bolts of what's happening, my computer is more of a tool than a programming machine.
Will it ever get the backing of Redhat? (Score:2)
I don't think that redhat will ever give an automated-updating package manager their full support. It's a pain to get all of the little dependencies for RPM(this depends on that, which depends on those 8 packages, two of which require a new version of pacakge q), which helps them sell cds.
This is not at troll, but honestly, redhat has to sell cds, and I belive they have held back support for automatically updating package managers because they would rather have their users go out and buy redhat cds.
Now Eazel and I belive helixcode are gearing up to offer subscription(money)-based automatic system updaters, and I remember hearing something similar from redhat at one point. But I doubt they will ever support one for free. It's a sad fact that often technology advances are held back because a company needs to make money.
An interesting thing to try would be to make it so you could do bug-fixing upgrades (1.0 to 1.1) but not feature upgrades (1.0 to 2.0). And in order for that upgrade you would have to be running the new version of Redhat. "6.0 lets you upgrade from 1.0 to 1.1, but to get the added functionality of 2.0 you need to buy version 7!".
Re:Could someone enlighten me please... (Score:2)
Re:Could someone enlighten me please... (Score:2)
Apt-get.
Cleaner dependencies.
More package maintainers.
More packages in the standard tree - fewer compiled by other people who are not part of the distribution.
More testing.
Debconf.
No backward compatibility break between rpm-3 and rpm-4 for debs.
Nuff said.
So ugly (Score:2)
I thought web sites were supposed to look more like applications in order to be more usable, not the other way around.
Who designs this crap?
Re:I'm so sick of... (Score:2)
Re:Dept of Redund Dept (Score:1)
Or NIC card, Or RPMs...
Re:It's about bloody time (Score:1)
It will support 7. (Score:2)
As for "silently" dropping 4.2, it's not really true. We have always supported the end-of-line releases for the last 2 major versions, meaning 4.2 was dropped when 7 was released, 5.2 will (unless our policy changes) be dropped when 8 will be released. I'm quite sure this information is publically available somewhere.
Aduva Manager... (Score:1)
ADUVA RESOLVE LIBRARY BETA TEST LICENSE AGREEMENT
Section 1.
"a limited, non-exclusive license and right to non-commercial use of one copy of the Program on your desktop computer or on a portable computer, all for the purpose of testing the Program."
This leads me to believe this will not always be free. You could end up paying for this "service" (the use of their database). Doesn't that violate some of the previous Licenses? After glancing at this, I doubt I will use this. Sounds to sketchy to me.
Re:Dept of Redund Dept (Score:1)
You'd be correct if the files handled by the Package Manager were of the type R. However the actual file extension/file type being RPM the correct term would be RPM package manager. Going along your train of thought, deb package manager would also be incorrect.
Um... Yeah. Redhat package manager package manager? "deb" isn't an acronym, "rpm" is.
Re:Dept of Redund Dept-OT IGNORE (Score:1)
Re:It's about bloody time (Score:1)
And now I am at it, I had to download a lot of drivers etc. before I could start on the network install. I can't see why it couldn't just put all the essentials on one floppy and then get the rest of the base system over the network.
Oh, and dselect is a horrible user interface. They really need a good graphical one under X. (I use apt currently)
But when installed debian is really nice and robust. After all, why else would I use it?
this will be taken as a flame. (Score:1)
in fact, i wish all the distros would re-center around debian.
how much energy has been spent here, supposedly making "rpm as good as debian", when debian is already the standard of excellence?
imagine redhat's prowess at making Linux easier...applied to debian. really, all these offshoots seem to be a waste of creative energies.
I'm with you there dude! (Score:2)
Re:The shifting sands of Linux (Score:3)
They won't respond to emails inquiring about this, either; not even to say "we don't have a time estimate yet".
So, I just continue to report to my Fortune 100 employer that RedHat doesn't have an auto-update solution yet, and doesn't respond to email.
-
it's a step, but in the wrong direction (Score:1)
"RPM Package Manager" (Score:2)
--
Re:Uh, fellas... (Score:1)
Licensing (Score:5)
12. Access to the ADUVA Server
Aduva provides at present free of charge access to the ADUVA Server and to the
ADUVA KNOWLEDGE BASE. Aduva may charge in the future for access to the ADUVA
Server and/or the ADUVA KNOWLEDGE BASE. The information and/or any other data
received from the ADUVA Server is the sole property of Aduva and is protected
by copyright and other rights.
I wonder if they have a privacy policy...
--
Give a man a match, you keep him warm for an evening.
Re:Package Managers (Score:1)
It's always been my opinion that Slackware is the best (and hardest) distribution of Linux to start out with, because you learn HOW to do things the hard way. This is an important step in the learning process. The next step is to learn how to do it BETTER. I do not recommend Debian to new users unless they are coming over from Solaris or other commercial Unix. Its not for novices trying to learn with, its for Linux users who have a job to do.
Re:this will be taken as a flame. (Score:1)
Use what you want, but dont try to convince someone else that their dist is so inferior to yours. The major advantage of Linux is choice. No one vendor, no one controlling group.
bero (Score:1)
use LaTeX? want an online reference manager that
Re:I'm so sick of... (Score:3)
Re:Aduva Manager... (Score:1)
Re:The Two Cultures once again (Score:1)
Go the binary, get the
running 'make install' won't help you understand anything about the source, you must spend time to read and track the source. considering i have over 800 packages installed, the compile-all approach would only work will on a 486 with a 100mb hd.
Re:Licensing (Score:1)
apt-get is superior
Re:So ugly (Score:1)
--
Re:But does it have support for... (Score:1)
Re:Package Managers (Score:2)
i agree; that's how i learned *nix system administration. but it gets old pretty quick, when you have to download, configure, compile, install and tweak a dozen or so programs just to have a system that does what you need it to.
once you have reached the level where you understand what is going on, you will start looking for a way to remove that drudgery. for me, debian was the way. most packages install and work out of the box, so most system admin tasks involve customizing your setup, e.g. to make apache do a bunch of virtual hosts.
as for your problem with X, what do you expect when you run the unstable distribution? if you want a rock-solid system, use potato.
oh, and X takes several hours to compile. so you wouldn't have saved that much time anyways.
--
Re:Could someone enlighten me please... (Score:1)
This may be true when your user base is elite CS Grads at Berkerly, but you have to wonder if these days Linuxs user base is not as tech-savvy as it once was, back in the good old days of v1.119
Honestly, this might sound a bit dumb, but I don't see what is so difficult about using gzip, tar and gmake. I mean, if you cannot figure out a few simple commands, maybe you shouldn't be using Linux in the first place !!! Its not for joe average, its for people who like to get under the hood and tinker around.
Re:Could someone enlighten me please... (Score:1)
Erm, actually RPM has had optional pre- and post- install/uninstall script capabilities for a while now. At the moment they're mainly used for running ldconfig, though I have seen them used for generating post-install SSH keys, and for setting an SQLd password interactively from the shell prompt.
I wonder how well GnoRPM would cope with that, though...
Re:The shifting sands of Linux (Score:2)
--
Re:It's about bloody time (Score:1)
What all Linux Package Managers Lack... (Score:5)
One of the things "enterprise" Unices have is the ability to upgrade a package, while the system backs up your old package. If the package upgrade breaks something, it's simple to roll back to the prior state. If everything goes OK, it can be run through it's paces for a while, and then eventually "committed", whereby the old information is deleted.
Until some flavor of Linux adds this to their package management, Linux WILL NEVER be able to take over the corporate world (yeah, there's a lot of other things it needs to, like 32-bit UIDs and a journaling filesystem, but at least they're on their way).
Licensing (Score:2)
Date: Wed, 27 Dec 2000 22:31:05 +0200
From: Ury Segal
To: egon@tuininga.org
Subject: Aduva Manager Privecy issue
[ The following text is in the "windows-1255" character set. ]
[ Your display is set for the "ISO-8859-1" character set. ]
[ Some characters may be displayed incorrectly. ]
Hi!
I am Ury Segal from Aduva.
I just wanted to say, in advance to the answers to your question you'll
probably get tomorrow ( It's 22:27 here ), that your privacy is kept, and
Aduva Manager does not send the inventory of your computer to our
servers. All we have is your IP ( and what you asked to download -
but that's just any FTP site can do. )
We are making the sources ready for GPL, and then you'll be able
to check my claim, but till then - you can either sniff the packets and
see for yourself, or just believe me
(The stream is SSLed, but it's sniffable if you are
on one end )
--
Ury Segal
Aduva INC
Phone: +972-3-7534300
Fax: +972-3-7534343
--
Give a man a match, you keep him warm for an evening.
Integration (Score:3)
Unfourtunately, this have been done a lot lately, mainly by KDE developers (No offense, you make a really good GUI, and some really nice functionalities, but could you please separate the two?):
* KMail have functionality to download mails and filter mails to different mailboxes (It should have used fetchmail and procmail for that, and provided only a graphical configuration tool for those two backends).
* QT contains both basic datastructures (Linked lists, hash-tables, etc) and GUI widgets (Buttons, listboxes, etc). In GNOME, those two parts are separated in Gtk+ (GUI widgets) and glib (basic datastructures).
* KDE contains a virtual filesystem that enables the user to transparently use files on remote sites using any KDE application. This functionality should have been in the operating system filesystem layer (There are several projects to achive this (portable): Podfuk, Alex, etc) VirtualFS), since as it is now, only KDE applications benefit. Here I might add that GNOME are unfourtunately heading for the same, developing the gnome-vfs (which stems from the Midnight Commander VFS).
www.adbusters.org (Score:2)
What is the Aduva business-model? What are they planning on doing to feed themselves? Does anyone know?
A Couple of Points of Clarification... (Score:2)
There seems to be some confusions as to what a "package manager" really is. This isn't an 'RPM front-end to apt-get" as Hemos put it. This is a port of apt to support RPM's as a package format. Debian packaging is done through 'deb' packages, which are almost identical to RPM's in form and functionality. Both have evolved to be very good package building, deployment, and retraction tools for software.
What this, Helix-Update, Eazel Services, apt, and up2date really do is function as package distribution channels. They resolve dependencies, check package location/availability against host-side maintained repositories and download the appropriate packages, once all the dependencies are figured out and resolved. They do not install the packages -- the package manager (RPM, dpkg) does this part. (Well, technically they can, but this would be through either re-writing, or linking to the library form of the package manager.)
While noone can argue that Debian had this capability first, and probably (currently) does it best due to having time to mature, it's natural that this capability will come to other distros and package formats precisely because it works so well.
Cheers,
Ken Crandall
Skinnable? *sigh* (Score:5)
I really hope that by "skinnable" you mean that it will use the widget set that your window manager & desktop environment provides, or at the very least provide that as an option.
That last thing in the world we need are 500 "desktop-ready" applications, each with their own skin format. I already use four different applications that have separate theme formats: XMMS [xmms.org], Nautilus [eazel.com], Mozilla [mozilla.org] and gkrellm [gkrellm.net]. Combined with GTK and Sawmill, that's 6 different theme formats I have to keep track of. (Well, that's kind of a lie; I have Mozilla installed so I can use Galeon [sourceforge.net]...)
I don't need a themeable package manager, ICQ client, mailreader, image editor, web server, and SETI@Home client. Desktop environments provide those widget sets for a reason...
Jay (=
Re:Hierarchical package display (Score:2)
Debian stuff (Score:2)
Yes, RedHat, SuSE, Mandrake, etc are easy to install, very easy, like i can put the disk in, boot, select the shiny red button for 'install' (figuratively speaking) and it'll set all the defaults and select all the basic, normal packages. I don't have to do much. Sometimes, like with that Mac, I don't mind a challenge, but when it's just giving me a headache because I want to be able to play sounds or talk to my NIC, it's quite annoying.
Just my two cents worth...
"Titanic was 3hr and 17min long. They could have lost 3hr and 17min from that."
Re:Could someone enlighten me please... (Score:2)
>>>Linux in the first place !!! Its not for joe average, its for people who like to get under the hood and tinker around.
I disagree... It may have been that way before, but more and more windows users are moving to linux, probably just because of the hype so they are curious. But the easier it is for any user to install and maintain packages, the more users will stay with linux. Sure sometimes its a good idea to compile the sources, but if there's already a package out there, it's just a waste of time. Ideally, no user should ever have to compile the sources- just have it there in case they want it. The thing that is keeping that from happening is the lack of a standard packaging system. RPM works fine, but I really like the apt-get feature of debs. But now that apt is being ported to rpm, then I think I'll just stick with rpm. In the meantime, whoever makes package management easier has got my support.
But on a side note, I think the interface for this piece of software is ugly and is poor UI design. I personally cant wait for RedCarpet [helixcode.com] from Helix [helixcode.com] to be available - that looks like the best bet right now for package management.
-Brandon
Re:Licensing (Score:3)
Is this different from the policies for the Eazel and Helix Code updaters? They're planning to eventually charge for use of their databases as well. (Hint: That's how they might conceivably make money.)
The real question is whether the Aduva source will be released -- and according to the license page it will be, under the GPL.
Re:Could someone enlighten me please... (Score:2)
Re:What all Linux Package Managers Lack... (Score:2)
-bluebomber
Re:Could someone enlighten me please... (Score:2)
Profit, that's why! (Score:2)
If one could apt-get distupgrade a Redhat box ad infinitum you could buy their distro once and upgrade from that point forward. Debian is a non-profit organization and does not worry about cashing in on the next point release. Debian users upgraded from 2.1 to 2.2 by issuing a simple command. Redhat users sometimes have to deal with dependency problems if they want to upgrade a package and you can imagine what could happen with hundreds of packages.
Redhat benefits when people buy their distro. They might benefit if they could provide an apt-get frontend with a subscription based service. Although I would love to see an apt-get front end thats free to all, I bet the suits at Redhat corp won't let this happen. I could be wrong, but I think the use of a tool like apt-get and especially doing a distupgrade on a Redhat box is about profit and nothing more.
Re:Package Managers (Score:2)
Re:Licensing - This is not free software! (Score:2)
2.You may install the program yourself, but you must do so in accordance with Aduva's instructions. The Program is licensed, not sold. This license does not confer you title or ownership in the Program. The Program is not subject to any General Public License and is in whole or part the proprietary property of Aduva. You are specifically prohibited from reverse engineering the Program.
7.Confidentiality. All elements of the Program, the servers it attaches to, the manner of operation thereof, the code thereof and the information relating thereto are considered confidential information and you agree to maintain such information absolutely confidential and not to disclose such information to any third party whatsoever without first obtaining Aduva's prior written consent.
More (including a nasty termination clause) can be found on http://www.aduva.com/mason/new/licenses.html [aduva.com]
nice! (Score:2)
1. compiled and added sound support for my ES1371 (I didn't know that I have sound card onboard, heh)
2. Upgraded my Netscape to 4.76 - security update (thats nice!)
3. updated my gtk
Then I selected the kernel and clicked Upgrade Now - and it downloaded and compiled kernel 2.2.17 quite nicely..
Overall - I really like the program - I just really hope that they'll replace the BUTT UGLY GUI and add the option to let me resize the window (it looks very small on EXCEED on my NT when I'm running 1600x1280)
Good work Aduva!
YoGi
Re:I'm with you there dude! (Score:2)
Nop. QT 2 is being used.
Re:props for Conectiva (Score:2)
Re:Aduva: free for non-commercial use only (per FA (Score:2)
Re:Licensing (Score:2)
Re:props for Conectiva (Score:2)
For example, building packages depending on obsolete packages, or packages conflicting with the distro's official packages, is a good way to break apt-get in both Debian and Conectiva.
apt-get with Red Hat (Score:2)
Re:Licensing - This is not free software! (Score:2)
Given that they say they are going to GPL it, if they are not currently linking to a GPL component, they aren't doing anything wrong.
Not that I am sure the business model makes much sense. There are too many people willing to give away what they are seeking to sell.
Thanks
Bruce
Re:The shifting sands of Linux (Score:2)
Thanks
Bruce
If you want source, but also pkgs, use src.rpms (Score:2)
I love src.rpm packages for simple reasons, they make instalation and removal a cinch, but at the same time they have all the advantages of source.
I can recompile with opt flags, change install paths, apply custom patchs, and build myself a nice reusable rpm file for later use.
For all the people who complain about package systems "robbing me of control" try using src.rpm packages more often, there easy to use, flexable, and give you a nice clean souce tarballs that you can tweak to your hearts content.
Oh, you mean like rpm -U --oldpackage? (Score:2)
Well, technically RPM will automatically deinstall any obsoleted packages on an upgrade, and so you'll also need to grab those as well, but this doesn't happen to often. Besides, you can always do:
rpm -q -a | sort >before
rpm -UvhF *.rpm
rpm -q -a | sort >after
It shouldn't be too hard to put together a wrapper for RPM that does that, and then reinstall all the older packages if you want to back out.
---
Re:Could someone enlighten me please... (Score:2)
Apt-get.
Which is an update program, and not a package program. Mandrake has MandrakeUpdate (along with stable and cooker sources), and I'm sure most other rpm based distros have similar tools.
BUT - this has squat to do with .deb versus .rpm.
Cleaner dependencies.
Is that a function of the format or the package maintainers?
More package maintainers. .deb file format versus .rpm.
Again, has nothing to do with
More packages in the standard tree - fewer compiled by other people who are not part of the distribution.
Again, squat to do with deb versus rpm. And for that matter, Mandrake's Cooker has most of what I want, being an open submission of Mandrake rpms.
More testing.
Hunh? I'm not sure what that means, but I don't think you're referring to rpm versus deb as packages.
Debconf.
Okay now THATs more like it - can a somewhat less zealot debian user explain debconf? I'm seriously interested in deb versus rpm (Corel's distro for a two month period was as close as I got to debian).
No backward compatibility break between rpm-3 and rpm-4 for debs.
Bzzzt. Thank you for playing. It works fine on my system.
Nuff said.
Not only did you manage to sidestep the direct question (rpm versus deb as packages, leaving package managers/updaters out of the scope of the discussion), you merely named a whole bunch of utilities that would only be recognizable to debian users, who, presumably, would not need the information.
Any debian AND rpm user out there care to take a crack at explaining the difference and pros and cons between the package formats?
--
Evan
Re:Could someone enlighten me please... (Score:2)
Seriously, the reason Debian doesn't use RPM is because R=="Red Hat" IMHO. That's the vibe I get from some folks who're involved in Debian. "Ick, that's a RH thing," I've heard more than once.
Actually... (Score:2)
Helix Code is working on such a program that they call IIIRC a meta theming engine. It currently has support for Gtk, Sawfish and XMMMS but it should be very modular.
For x = 1 To null (Score:2)
Re:Could someone enlighten me please... (Score:2)
Which is an update program, and not a package program. Mandrake has MandrakeUpdate (along with stable and cooker sources), and I'm sure most other rpm based distros have similar tools.
Ever tried to use those tools ??
You are right though - this is not strictly a deb vs rpm issue.
More packages in the standard tree - fewer compiled by other people who are not part of the distribution.
Again, squat to do with deb versus rpm. And for that matter, Mandrake's Cooker has most of what I want, being an open submission of Mandrake rpms.
Actually this has a ton to do with reliability. The entire point of having a distribution is that they will ensure that packaging is reliable and consistent. When third party vendors start offering Redhat RPMs, or Mandrake RPMs, or you start using contrib RPMs, package dependencies get less consistent, and the machine is just not as clean.
I get everything I need at debian.org in woody non-us and non-free, all packaged by debian maintainers.
Debconf.
Okay now THATs more like it
Debconf is a little scripting conf that allows packages to pop up questions in console windows during the package installation that ask you if you would like to clobber your existing configuration files with new ones or not. The default is always do not clobber. Or, a package can pop up a reminder about a configuration issue associated with a package, and either show or do not show the reminder in the future. Lastly, they have help hints if you cannot resolve a dependency that tell you what to do !! These have helped me a few times.
Re:+5 Insightful (Score:2)
Privacy policy. (Score:2)
--------------------------------
Re:Package Managers (Score:2)
I've use Slackware before with no problems, and I think the whole idea that Slackware is "hard" is largely outdated. Yes, Slackware used to be more difficult to pick up than something like Redhat, but recently Slackware is not any more difficult or more educational than anything else. Really, is './configure && make && make install' that much more difficult than 'rpm -Uvh' or 'apt-get install'? Slackware even has it's own package management system now too.
Sure, it's supposed to be the most "UNIX-like" distribution, but what is really UNIX nowadays; with Sun's own CEO calling Solaris "Sun's implementation of Linux"?
Re:The shifting sands of Linux (Score:2)
It has been released for some time now - look for up2date 2.1.7
As for emails, who did you send them to?
up2date has just been changed (Score:2)
Re:Could someone enlighten me please... (Score:2)
Red Hat (and almost all the other distributions) use RPM because it works well and is a better and more flexible package format than deb. You're probably confusing "rpm being superior to deb" (package format) with "apt is cool" (distribution of packages)
RPMs, in contrast to .deb, has cryptographically signed packages (and has had so for ages), flexible and reproducible building method (look at a spec file, they really tell you how to build a package), separated patches(I've seen people claim than .deb can do this, but as long as the packages distributed with Debian don't seem to do this I'll believe that as an urban legend). Take a look at a SRPM and a Debian source package - there's really no competition.
up2date can do this (Score:2)
Just run "up2date -u", and it will update your system from the command line.
It can be configured with up2date-config, so if you just want to download the packages or mark certain packages to be skipped you can easily do that as well.
Re:Will it ever get the backing of Redhat? (Score:2)
Re:Could someone enlighten me please... (Score:2)
Really? Mmm... Do you also purchase only Microsoft software, avoiding those nasty "other" vendors that prevent you from having a "reliable and consistent" experience? Because you could replace "Debian" with "Microsoft" there and have a sentence that could come from any number of idiot NT admins that I've run into.
Point well taken, but the environment is completely different. Everything I need under linux is free (as in speech), and can be packaged by a single party. And the single party is not a vendor with a monetary incentive to lock me in, but a collaboration of hundreds of volunteers.
There is nothing preventing RedHat from packaging everything that is packaged as RPMs for RedHat from third party vendors. The packaging basically consists of taking the installation files, and wrapping them together, setting sane dependencies, and pre/post install/uninstall scripts where appropriate.
Put another way, in a Microsoft world one of the single largest sources of OS trouble is third party software clobbering system dlls. If Microsoft could package that software properly, Windows would work much better. Of course, in a Windows world the third party software is actually competition, so this would never work.
In free software the third party software is a welcome addition to strengthen the distro. See the difference yet ??
The
This may surprise you, but Debian as a distribution is still growing rapidly. And the net number of people converting from RPM based systems to deb based systems is substantial.
But that is beside the point. Debian will continue. Its volunteer packaging force is growing rapidly, as is its user and testing base. There is no monetary bottom line affecting the distribution - only the joy of having free software that works the way it should. As long as the packagers keep packaging, the distro will continue. As long as the userbase keeps expanding, it will grow stronger and stronger.
Re:Could someone enlighten me please... (Score:2)
Not an issue for at least RH and, presumably, other RPM-based distros (though I don't know, so I can't swear to it). RH just runs out and makes an rpm-4 compatible version of rpm that runs on old distros. Easy. Fun. Besides, presumably all the reinstalls you've had to do when the unstable Debian tree breaks your system add up to at least some form of "upgrade", hence lack of backward compatibility?
If you don't want to have to fuss with it, simply use the stable tree - that is what it is there for.
If you don't mind the occasional manual futzing with your box, the Debian unstable tree is for you.
And if you want a real pain in the ass, use a RedHat *.0 release. Totally unstable compared to Debian unstable. And RedHat calls it a production release.
Don't get me wrong - I administer RH and Debian boxes. I find I spend much less time screwing with the Debian boxes, and the initscripts and cron jobs (slocate, man) do more intelligent things. Like, for example, wiping
Basically, I tried Debian as an experiment. It was slink, and a royal pain to install (potato is supposed to be much easier). Then it was a pain to get everything the way I liked it, as I didn't know much of apt and dpkg. Then, I used the box. And over a few months, I realized the Debian box was running more smoothly, and upgrading more easily, than the Redhat box. And this is mainly due to clean packaging and apt and debconf.
From Debconf's own description: "It's a way to get rid of all those annoying questions Debian packages often ask when they are installed; or a way to present them to the user via a varierty of UI's.". Gee. That's just swell. Instead of auto-detecting things like most RPMs do (following a Red Hat convention) and then letting you customize things if you want something special (rpm -i blah.src.rpm, edit
Really, it does things like
1) install XFree 4.0
2) Prompt you whether you want to make XFree 4.0 the default
3) Remind you that Debian XFree 4.0 uses the binary
4) Ask if you want to autoconfigure XF86COnfig-4 or use the existing version.
So you can see, you have multiple options, all of which any reasonable user might choose. With redhat you only get a broken system until you can hack up a new config file.
And for another example, for gdm, the debconf entry asks if you want to keep or overwrite the gdm.conf file.
More testing.
Again, not a
Really, this is critical. Debian packages get a little testing by the maintainers, and sometimes others who download them from a web page. Then, they get placed in unstable. Thousands upon thousands download unstable (since apt works so well), and an open bug reporting system checks all the bugs. The package is changed again and again until it is assumed everyone in stable can use the package without issue. Then it is moved to stable.
Redhat is trying something similar with rawhide, but it gets a few orders of magnitude less testers.
Re:Oh, you mean like rpm -U --oldpackage? (Score:2)
I just compile from source--that way all the problems are my fault:-)