Debian 3.0r4 Released 194
SeaFox writes "The Debian group has released an update to the 'Woody' distribution of the popular Linux/GNU OS. From the site: 'This is the fourth update of Debian GNU/Linux 3.0 (codename woody) which mainly adds security updates to the stable release, along with a few corrections to serious problems. Those who frequently update from security.debian.org won't have to update many packages and most updates from security.debian.org are included in this update.' But the question on everyone's mind is probably when the current Testing branch, featuring much more up-to-date packages, will be named the new stable release."
testing?! (Score:5, Insightful)
But the question on everyone's mind is probably when the current Testing branch, featuring much more up-to-date packages, will be named the new stable release.
Oh, come on! When will the submitter realize that stableis what most of us want to run on our servers and mission-critical hardware. I for one cannot afford doing an apt-get upgrade and breaking three, two or even _one_ package. Even worse would be putting a serious bug in the software on a production machine. With stable this chance is minimal, but of course not non-existant.
One possible solution would be to divide Debian into a "server version" and one for the workstations who actually _want_ (or need) to run stuff from testing. Although this would mean double the work for the package maintainers (et al) I'm sure it would make Debian even more attractive as a desktop alternative. Today, I don't know a single n00b or even semi-n00b using it for her home PC or similar - it's all Windows, Xandros or possibly SuSE. On the other hand basically all of my friends who proudly call them selves sysadmins are running Debian (stable) on their production boxes...
Unless of course they need to run RH to get IBM to support WebSphere =)
Re:testing?! (Score:4, Interesting)
Of course, another open-source group could provide this alongside the Debian Project
Re:testing?! (Score:2, Insightful)
Well, no need for that. The 3 main distros (stable, testing and unstable) simply represent the "level of paranoia"/package staleness choice one can make, i.e. stable is old stable packages, testing is reasonable up to date packages with a few problems, and unstable is cutting edge and you're on your own with problems.
What one may with is an additional level between stable (which is truly quite stale) and testing
with perhaps a pre-configured installer that
Re:testing?! (Score:2)
Synaptic?
Re:testing?! (Score:3, Insightful)
Why must the solution always require a X-window GUI? You've now required a huge amount of resources be deployed just to update/select packages for a DNS/printer server.
Aptitude/apt-get rocks the socks off anything I've seen and I would really hate to try and run some GUI over my internet SSH connection across the country just to execute my periodic 'apt-get update && apt-get dist-upgrade'
Re:testing?! (Score:2, Informative)
Re:testing?! (Score:2)
I know. I used SuSE for over a year. It's a pig.
Re:testing?! (Score:2)
-Erwos
Re:testing?! (Score:4, Insightful)
Ooh, bad idea. Multiple vendors (amongst them Microsoft and RedHat) have already demonstrated that it's a bad idea for an OS installer to silently install services/daemons. When an exploit comes around, someone *will* write a worm and say bye bye to your credibility. Because there'll be an aweful lot of people who didn't even know that Apache/Sendmail/BIND/whatever was installed on their machines and didn't know to update. No siree, I like the current trend of disabling services/daemons on installation. Even better, Debian often sabotages config files to force the admin to spend at least a little time looking at a config file before firing up some daemon.
Re:testing?! (Score:2)
Actually I would not call it sabotage as I usually see a good default config file that will work for most people. What I am seeing more and more are files in
Re:testing?! (Score:3, Informative)
WTF? (Score:2)
Re:testing?! (Score:1)
That would be the best way to go but wouldn't that also restrict features and perhaps some secrity loop-holes in the long run?!
Re:testing?! (Score:1, Interesting)
Even though sarge is "testing" It's been really stable and also my choice for desktop use.
Re:testing?! (Score:1)
Though of course I am running a smaller risk, but usually I just upgraded a smaller box first to see if anything was broken - didn't encounter one broken thing yet... it's unstable (codename: sid) that gives me the most if any problems of course I have never, and will nev
Re:testing?! (Score:2, Insightful)
If you really need MySQL 4 that bad then why don't you use backports.org [backports.org] which will allow you to run stable and yet keep some newer packages on your box?
Re:testing?! (Score:5, Informative)
One possible solution would be to divide Debian into a "server version" and one for the workstations who actually _want_ (or need) to run stuff from testing.
Or you could, you know, actually run stable on your servers and testing on workstations. Debian will let you mix and match, it's called pinning [sbih.org], and if you're not willing to run testing or unstable, Debian Backports [backports.org] provides modern packages compiled for stable.
The system you're describing already exists, you just need to know how to use it.
Re:testing?! (Score:4, Insightful)
Backported pacakges are insecure. You should only use the binary version if you trust the person who compiled it.
True, but have a look at Ken Thompson's well-known presentation, Reflections on Trusting Trust [insan.co.id]. Can you trust your own compiler? Unless you can manage to manually write a trusted bootstrap environment to your hard disk, with which you only compile code that you've fully examined yourself, at some stage you'll need to trust that the toolchain you are using is safe, that the applications you are using are safe, and that at in any number of possible places where it could occur, no one has maliciously tampered with your sources or binaries.
I don't know anyone involved in Debian or any other Linux distro. How can I really be sure they aren't bad guys? Why should I trust them any more or less than the people behind Debian Backports?
In any case, you can always download Debian source packages from unstable, and attempt to compile them yourself on a machine running stable.
Re:testing?! (Score:2)
What's it like to be so afraid of the world that you never leave the house?
I have no idea. I'm not so paranoid that I don't ever use binaries from people I don't know; obviously without gcc, glibc, or the Linux kernel I wouldn't get very far. The grandparent AC said 'You should only use the binary version if you trust the person who compiled it.', and I'm simply trying to illustrate that unless you happen to personally trust the very large number of people involved in putting together your operating sys
Re:testing?! (Score:5, Interesting)
Please don't...
Debian already has four levels of version: stable, testing, unstable, and the new expiremental. Adding any more levels or options to the process will only slow down the release of stable. I really don't think you want to wait for the next release of Debian Dorever 3D do you?
If you want a server version then stick to stable. If there's a package that you need that's newer then selectively import that from testing while keeping the rest of your system stable.
It's a cute sounding suggestion, are you the one who is actually going to have to live with it, or are you trying to sound intelligent? You forget you are dealing with a voluneer group. If you add a shitload of beaurocratic complexity to the process you will have to start paying them to put up with your stupid ideas.
I've worked will someone for over a year on using Linux and they have settled on SuSE. They don't like it, but they just don't want to learn anything more about it. They have to settle for a lot of things that they can't do or can't do right.
Adding more distribution levels to Debian will only make things more difficult to manage. Don't fuck with it unless you want to fix it yourself.
When are you going to realize that there will always be two types of users on computers? Sheep and Geeks. Sheep like to download virus and spyware and adware and if they can't have butterflies for their mouse pointer they shit themselves. And they don't care about anything else. Let the sheep use Windows and be stupid and pathetic and annoying and let the rest of us use Linux and have a clue and not have to deal with the sheep unless we need some money. Sheep pay a lot of money for stupid stuff. Don't fix it for them, or we might all be out of work.
Re:testing?! (Score:2, Insightful)
Stick with OpenBSD. It's more secure than Debian, and substantially more up to date package/version-wise.
Re:testing?! (Score:4, Interesting)
If you happen to buy a new computer, Debian 'stable' is too old to support the chipset, many devices and perhaps even the cpu (such as Opteron or Apple's 64-bit PPC). Otherwise, Debian stable is fine for new servers -- but only if you buy them used on Ebay!
They should reorganize their release names from stable, testing, unstable and experimental to Grandpa, Greybeard, Production and Current.
Re:testing?! (Score:2)
Re:testing?! (Score:3)
No, I was being unbelievably sarcastic.
I'm scared to death that in the name of "Ease of Operation" people will settle for the likes of SuSE at the sacrifice of Debian and Gentoo.
I spend more than a year running only SuSE around here and found that it was very nice to use. Just as long as you didn't try to do anything that they didn't anticipate. They have a good concept in management of a workstation/server. But if your needs deviate from their path, it becomes increasingly difficult to execute. Many
Re:testing?! (Score:2)
Re:testing?! (Score:2)
You don't have to do business with people who insist you use Windows. But that's your choice.
And I never said Windows users liked to fuck up they systems. But then sheep don't like being fed to the wolves either. Sometimes they don't know any better.
Sheep are very dim..
That's what Ubuntu is for. (Score:2, Informative)
Re:That's what Ubuntu is for. (Score:2)
So it's
no firewall
People should generally prefer the hardware firewall in their DSL modems/whatever, assuming that they have a box with NAT or actual firewall.
no firefox 1.0 last I looked
Yep, but installing the FF1.0 from the official package at mozilla.org works like a charm, and doesn't overwrite the old 0.9.3 or whatever it was.
and a host of other annoyances
Main annoyances are l
Re:That's what Ubuntu is for. (Score:2)
Re:That's what Ubuntu is for. (Score:2, Informative)
Duh! The "awful media replacement" is actually from Filesystem Hierarchy Standard [pathname.com] and every distro should follow it.
Re:That's what Ubuntu is for. (Score:2)
Re:testing?! (Score:3, Interesting)
Its simply a completly hopeless undertaking to try to get all multiple thousands packages in Debian stable stable at the same point in time, it simply won't work. And while this undertaking is already almost impossible at the release time of a new Debian stable, it gets rather pointless once the Debian stable distro got a year or more old. At that poi
Re:testing?! (Score:5, Informative)
Yes, but you don't want to install the current debian stable on new servers. It's just too old. Stable lacks the hardware support for modern servers (does Stable ship with a kernel which supports dual xeon machines with 2 GB ram? AMD Opteron? Modern chipsets? SCSI controllers?).
Debian Stable is good for old servers. Debian has no good offering for new servers. Nobody cares that debian can be installed in 48 MB of ram. 48 MB does not make a server. It makes an antique.
Debian should realise that if they want to make a serious server distribution, that people will want to run it on a server. A real one.
Re:testing?! (Score:4, Insightful)
If you seriously intend to put a stock distro kernel on it you have no deal setting up a "real" server.
Re:testing?! (Score:2)
I'd fire you for doing that. Seriously. All the top distributions (including Debian) do extensive QA on the software they ship, especially the kernels. When compiling your own software, you dismiss this QA and take your own responsibility for the software quality, knowing that the quality is usally less. And don't even get me started on security fixes. Do you want to keep track of all custom compiled software on all your servers and make high qualily security fixes under high pressure?
Of course I can comp
Re:testing?! (Score:2)
Ridiculous. How is software that was handpicked and compiled for the specific task by a qualified person worse than a generic distro package where often you don't even know what compiler version and flags were used and which exotic patches might have been applied?
If you prefer to not know what's running on your server, fine.
The fun ends when you sell tha
Re:testing?! (Score:2)
Now tell me if most of hte linux distro's are really that tested? SuSE particularly is very buggy.
If I were your boss I would fire you for installing free software that has not been testing for QA.
The redhat scare had to do with some patches for the stl library which many c++ unix programs needed to be ported to Linux.
In general Solaris and other unix adm
Re:testing?! (Score:2)
It is probably a good idea if you need 2.6 and you need it to be stable, but 2.4 is now quite mature and does not undergo very drastic changes. It would be pretty reasonable to compile your own 2.4 and expect it to be pretty stable.
Re:testing?! (Score:2)
Since none of the commercial middleware and relational database vendors support anything except the commercial "enterprise" distributions, running stock kernels and stock everything else, you're pretty much blowing hot air here. Unless you think tha
Re:testing?! (Score:2)
These are not servers within your responsibility. You buy them as blackboxes and expect oracle-support to keep them running for y
Re:testing?! (Score:2)
Ha. Not a professional DBA, are we?
Re:testing?! (Score:2)
Re:testing?! (Score:2)
1. You choose and know what will be running, including all libraries (starting
from glibc), patches, compiler and interpreter versions. No generic distro
package will be optimized for your purpose because no maintainer knows what
set of services is critical to you and what configuration options are
appropiate. You do not want to run public services with all kinds of
unnecessary modules and options compiled it (many of which could beco
Re:testing?! (Score:2)
"1. You choose and know what will be running, including all libraries (starting from glibc), patches, compiler and interpreter versions"
That seems good, provided you are a real expert on all those fields. I bet you aren't, so you are doomed to make bad choices here.
Guess what, it's my job and I'm getting paid to be an expert on "all those fields" (which really is just advanced unix knowledge).
"2. When something breaks you know
Re:testing?! (Score:5, Informative)
I want the distribution to be stable, but I don't mind keeping the kernel up to date myself. With make-kpkg, it's a snap to build Debian packages out of kernel.org tarballs and, on this machine, it just takes a few moments.
(And yes, if this really was a mission critical server, and not just a department build machine, I'd build and test my kernels elsewhere before deploying them, but that's not the point.)
Roll your own kernels (Score:2)
I'm getting to a point where there are things in testing that I need, I'll grab those packages from backports.
Xix.
Re:testing?! (Score:3, Informative)
And I think Debian Stable comes with SMP enabled kernel, so it should work with dual xeons with up to 4GB of ram.
Re:testing?! (Score:2)
Maybe the submitter meant he can't wait for the testing release to become the new stable one because most of the included packages are mature enough (Sarge seems to be lagging because they wanted to include gnome 2.8) and because security updates are done asap on stable.
As for making a "server" distribution, I think it's not worth the effort, as answering the FAQ "which de
Re:testing?! (Score:2)
Sarge seems to be lagging because they wanted to include gnome 2.8
Gnome 2.8 is now in testing, according to the last release update [debian.org]. The main delay is the security update infrastructure for testing.
Security updates are done ASAP on unstable too, so it's also an option if you don't want to wait for security updates to migrate into testing.
Re:testing?! (Score:4, Interesting)
Re:testing?! (Score:3, Informative)
Debian is most certainly not unmaintained in any sense of the word. Debian backports security fixes to the version in stable.
Re:testing?! (Score:2)
Interesting. I used to have FreeBSD on both my server and my two desktops, but I recently switched the desktops to Debian. For me the real issue was that certain ports just were old, or were not really working and available. For me, the biggest ones that mattered were inkscape (an old version is all that's available), lilypond (I have several pages of notes on the problems involved in
Re:testing?! (Score:2)
A stable Debian for the desktop? (Score:2)
Re:testing?! (Score:2)
Should that be interpreted as you suggesting you are a Debian missionary or something? I've observed that Debian seems to have a higher proportion of users who advocate it as the One True Linux compared to the other distributions. Only one of my many friends who are sysadmins uses Debian, and only for machines that have been around for awhile. The new stuff gets something like Gento
Re:Debian stale. (Score:3, Insightful)
That's why it is so long between stable releases... They have to make sure you can install and forget (except for the security fixes).
If you want a workstation use ubuntu, essentially a combination of testing/unstable. Or unstable.
A serious issue with old packages (Score:4, Insightful)
Something really needs to happen here (and installing 3rd party backported packages is not a clean solution). Perhaps a policy that packages that are no longer supported upstream will be upgraded in stable.
Re:A serious issue with old packages (Score:3, Informative)
As someone pointed out in response to another post, the same problem happens with Cyrus
Re:A serious issue with old packages (Score:2)
Could you have used Debians pinning to selectively upgrade PHP to the testing branch?
You've got a point about the slow fix to the flaw. But I don't believe the solution is going to be managed through adding additional levels complexity. But focusing on how to get the existing process to move more smoothly.
Re:A serious issue with old packages (Score:4, Informative)
The PHP issue was complex due to initially there being a lot of issues reported and ID's given which were later retracted.
All this was muddled by the PHPBB2 worm which the PHPBB people claimed for a long time was a flaw in PHP itself being exploited not a hole in their software.
Few people seemed to care to look into the situation carefully, had they done so they'd have released that woody wasn't vulnerable to several of the isses, eg these two [debian.org].
I found a bug that they wouldn't fix too. (Score:2)
The debian PHP maintainers arguement was that some people might be relying on that bug. I can see his point but it's such a broken bug that I still feel it should be fixed. It makes doing a for loop through an array that has been sorted unreliable so that you have to use for each.
you should use foreach (Score:2)
It makes me faint to think of you doing otherwise.
Sam
Any specific reason? (Score:2)
The only reason I did it the other way is that's what I originally learned bringing it over from ASP years and years ago.
Re:Any specific reason? (Score:2)
$object=&$array_of_objects[$key];
}
Because we have been permitted to see the growth and maturing process of PHP we see lots of weirdisms some of which are not ironed out till PHP5. This also means that in PHP4 (and evebn more so in PHP3) there are a few clumsy idioms like the one I gave above that need to be used but which really ought to have a more compact representation.
Some others are (remember that PHP arrays are ordered):
1) get the first item out of an array as
Not sure it matters which is stable (Score:5, Insightful)
Some packages, such as MPlayer, I know are tested enough by the development team that I'll take the newest version as soon as it comes out. Others I'd prefer to know someone else has taken some pain with it :-)
Just my .02 worth
---
For more of my ramblings, look here [blogspot.com]
Netcraft now confirms: Debian is obsolete (Score:4, Interesting)
Re:Netcraft now confirms: Debian is obsolete (Score:2, Informative)
include KDE 3.3 when it filters through. D-devel
has always been a bit like that anyway, FreeBSD will
possibly not give your boss what he wants or give you the breadth of readily installable packages.
Re:Netcraft now confirms: Debian is obsolete (Score:2)
Re:Netcraft now confirms: Debian is obsolete (Score:2)
Discussion summary (Score:3, Funny)
B: "Yes, but it's stable and it rulez in professional environments where you can't crash"
C: "Um, but Red Hat has pro support, if you're a pro"
B: "You can buy support from vendors"
D: "Don't people realize stable means stable, and testing means testing and it's wonderful that there are so many options?"
E: "My Gentoo system rox!"
A,C,D: link to sites like funroll-loops.org
F: Hypes up debian-based Knoppix.
G: Hypes up debian-based Ubuntu.
A: "Debian testing is still old, I need new"
B: 'You could try gentoo, you unfaithful kid".
yadda yadda yadda.
Re:Discussion summary (Score:5, Insightful)
The each have their own place
While there is a lot of pressure on Debian to move off the focus on stable and move towards being more current, this needs to be addressed not as a means of changing the process with greater options for the user community, but to address how the existing (and proven over years) process might be better improved upon. Much has been done through automation of the defined process steps already.
stable as a fossil (Score:2)
Current is oftenmore important than stable where "stable" is stable beyond the practical life of the hardware and "stable" wont install on new machines.
Fossils are stable too, but not much good as meat.
As is pointed outm "stable" is just a label though, and although calling something less stable "stable" doesn't make it so, and you can selectively pick pages from "testing" and do your own security fixes.
I think security fixesfor testing, and easier pinning control in dselect would
Debian Unstable (Score:4, Interesting)
The Debian "unstable" branch is as stable (at least for me) as any Linux distribution that I have used. Fast, too.
Re:Debian Unstable (Score:5, Informative)
The guidelines for unstable/testing/stable as basically as follows:
All new packages are in unstable
After about 2 weeks, they are moved to testing, if there are no major bugs
At release time, they go into stable.
Thus, if you'd download the latest version from sourceforge, or any kind of "nightly build", you may as well use unstable. If you only use things that have been tested first, but like recent software -- use testing. If you need the best testing availabe (without, of course, paying for testing or doing it yourself!), go with stable
Re:Debian Unstable (Score:2)
If you only use things that have been tested first, but like recent software -- use testing.
No no no. testing doesn't get security updates whatsoever. If for whatever reason sec-update package is bugged, it will not propagate to testing. This will make the 2 week delay even longer, possibly putting sec update off for a very long time. It's stable or unstable, testing is just to have new stable in a few years.
Re:Debian Unstable (Score:2)
So perhaps choose another name for this branch: incoming? bleedingedge? cuttingedge?
Re:Debian Unstable (Score:3, Insightful)
Re:Debian Unstable (Score:3, Informative)
I use Debian more because it's designed, or has the appearance
Re:Debian Unstable (Score:2)
Like any distro adhering to the LSB, or in reality just about any distro except Slackware or Gentoo.
Re:Debian Unstable (Score:4, Informative)
I've been running Debian stable systems since '97 or so. I did some recent short-term work where I had to build and support some Red Hat Enterprise 3 systems and some Fedora Core 2 systems.
Talk about "fun" problems. I got all manner of grief from Red Hat's Linux kernel. I had a particularly fun one where every couple weeks the cached copy of one of the filenames would have a corrupted last character. So I compiled and installed a new kernel from the base linux source. I had also set the / partition to "rw,noatime" instead of "defaults" in
And don't get me started about "up2date", Red Hat's version of apt-get. Damn thing gets stuck in infinite loops consuming 100% of the cpu until killed hours later. And no, the most recent updates havn't fixed it. Nor did following the instructions for regenerating the
My point is: I don't want to run anything as unstable as Fedora or Red Hat. That's why I chose Debian in the first place. So why would I want to run Debian Unstable?
I do want to see SOME forward motion though. Its long past time for those few package maintainers that are blocking testing's release to stable to either buckle down and get it done or be replaced.
Maybe it would help if they halted updates to those maintainers' packages in unstable and experimental until testing was releasable.
Re:Debian Unstable (Score:2)
Fedora Core 3 was one of the buggiest distros I've used. If Debian Unstable is still like that (which it was when I used it a year or so ago), I wouldn't use it for anything beyond a test system.
On Fedora: gnome-volume-manager died all the time on unmounting memory cards, syncing to my Palm wouldn't work (kernel patch problem), xemacs wouldn't maximise, up2date would say "Updates available" in the notification area and then refuse to
Testing, Sid, or... (Score:5, Interesting)
The problem is that even though sid is fairly stable compared to other popular Linux distros (though things do break occasionally), others in this same story, and rightly so, have said they would never use sid for a server. The whole purpose of stable is for running a server these days. I'm sure there are some users out there that may use stable for purposes other than a server (Bonzai was good enough for me for low resource hardware, when I installed it, it was based on stable, don't know now). But most users who are installing stable on a new server, with new hardware, have rightly pointed out that many pieces of the new hardware either don't work, or if it is possible to get working, have to be heavily hacked.
If stable were newer, it may be considered more for company installs, as long as the Oracle or Websphere, or whatever other certification doesn't require Red Hat or Suse. And I'm sure that even in companies that run Red Hat or Suse for some applications that need it, may also run Debian Stable for some purposes where they can just set it and forget it!.
I've tried stable in a newer computer. And besides the difficulty with some hardware, I found X with XFce difficult to use. Even though it is a server install, I still find it easier and more productive to install and use KDE gui apps for administration. Sure, I use the server for development also. It isn't my main development box. But for tweaking some html here and there, dragging and dropping files here and there quickly, and for some other purposes, I simply prefer a gui to do it with. I would've used Firefox (wasn't out yet) or Mozilla with another app for file browsing, but I like konqueror for web and file browsing (and fish/ssh) and a few other utilities it is good at. And though KDE is really bloated and I'd like to free up some space (every time I try uninstalling something KDE related, it wants to uninstall most or all of KDE or important libraries, like trying to uninstall XMMS, or other KDE utilities or apps), but KDE or synaptic won't allow it. Synaptic is another reason for my running X. And that I also wanted to try out Quanta Plus.
The release I'm using on the server is testing. As some other posters have suggested using. But the problem with testing is that it doesn't get the attention of the security team. I believe this changed a month or two ago because testing is close to going stable. But I'm not aware of a security repository for testing. I'm sure I would have seen an announcement about it here on
If the testing distro did receive the attention of the security team, and there were security repositories, then that would make testing far more palatable for many users as a server distro. With careful updates/upgrades, it would be a good solid release for a server, with much more up to date applications.
My testing distro was once Mepis. But once installed, I uninstalled some unnecessary apps, fixed my sources list, and slowly but surely, the install is becoming 100% testing. It currently has KDE 3.2.3, instead of the KDE 3.3.x version. I haven't taken a look at KDE 3.3 yet, nor do I plan to install it, as that would entail switching to unstable for a few repositories, and pinning, two things I don't want to do. But KDE 3.2.3 is working good for me, and as I stated, it is on a server install, so the latest and greatest isn't necessary.
I had planned on waiting (when Bonzai didn't work out for me) for testing to become stable. Good thing I didn't, because I never would have got anything done. Since I got tired of waiting though, I installed testing, and now hope KDE 3.3
Re:Testing, Sid, or... (Score:2)
Re:Testing, Sid, or... (Score:2)
Why? They can do exactly the same thing with RH or SuSE's enterprise editions. That's one of their main selling points.
Re:Not to troll but.. (Score:4, Informative)
Re:Not to troll but.. (Score:2, Insightful)
Re:Not to troll but.. (Score:3, Informative)
I hear that a lot, and occasionally someone who knows the differences between rpm and dpkg comes out and says what the differences are. I forget what they are, but I don't believe they are anything that a regular user might care about. rpm and dpkg are basically equivalent.
Has anyone noticed that the RPM distributions are starting to use the apt-get approach?
Of course, is there something in dpkg that makes it more suitable for apt/yum like functionality than rpm?
Re:Not to troll but.. (Score:2)
Are you asking for Debian to switch to RPM because it's better or because more people compile software in RPM formats?
Do you realize just how hard it isn't to compile software in .deb formats as well? Might it make more sense to use the better of the two packages in the long run rather than going with the most popular?
Of course, you've already answered that question because you are using Linux in lieu of Windows.
Re:Not to troll but.. (Score:2)
No, I would like to see a simplification of the skillset needed to operate a Linux system. Especially if the other alternative is not "better", only "different".
Obviously we are talkin about Debian here, where politics are everything and egos are on the line, so I'm not exactly holding my breath...
Re:Not to troll but.. (Score:2)
The egos problem will take care of itself in time.
As soon as someone develops a package management system that's better than Debian, rather than just duplicating it, then Debian will be in a position to lose.
Gentoo has a lot of potential on their package management system, but I've been repeatedly burned by their lack of basic safeguards in configuration and updates. For example: who would ever upgrade their /etc/fstab table from their own system to the one provided as default (which is empty). This is
Comment removed (Score:5, Insightful)
Mod parent up (Score:2)
Wouldn't it be trivial to add package support to RPM, then? A package could easily say that instead of this file, the package requires this package, this version? The coding/design feat doesn't sound like rocket science.
Or are there still other technical reasons?
Re:An explanation... (Score:3, Informative)
RPM can do this, too. IIRC, recent Fedora systems have dependencies on smtp-daemon, which can be satisfied by either sendmai
Re: (Score:3, Insightful)
Re:An explanation... (Score:2)
I disagree. The issue is that Debian requires you to do it a certain way. They could still do this if they used RPM. They have many other packaging rules that aren't enforced by the format, so I don't see any problem with one more.
They could additionally say "don't install non-Debian packages on a Debian system" and come up with a simple way to stop people from accidentally breaking this rule. (P
Re:An explanation... (Score:2)
This assumption is exactly where RPM runs into trouble. See An Analysis of RPM Validation Drift [usenix.org].
Re:An explanation... (Score:2)
man cpio
I say this, it is much easier to maintain RPM packages with their single
I also prefer the RPM principle of "pristine sources" which try to make it impossible to build a package from manually hacked sources, you need to provide a seperate patch file.
dpkg and apt stuff let you hack the un-tar'd source and then happily build from it. If you cant seeANY haarm in this then you don;'t understand the v
Re:Not to troll but.. (Score:2)
I agree with you that there are too many packaging systems out there. However, we'd be a lot better off if RPM would dry up and blow away, rather than Debian. RPM-based distros are a total PITA. You have to search all over the place for foo.rpm, and not just any foo.rpm but foo.rpm that's been packaged for your p
Re:Not to troll but.. (Score:2)
Dpkg really never breaks unless you have widespread disk corruption.
RPM breaks all the time (for me at least). Database corruption means all your package info is lost.
Dpkg, if 1 files gets corrupt, you just install that one package again and the files are replaced.
I think RPM has file dependencies. I don't know how I feel about these. I tend to think they aren't that useful.
Re:An update to APT (Score:3, Insightful)
All you do is add more than one source in sources.list. apt works through them in order until it hits a source without errors. Isn't that simple enough?
Settings up bittorrent trackers or gnuttella networks for this might be worthwhile as well.
A nice thought, but more open to tampering of the packages. I'm sure