ESR's goodbye note
| From: | esr-AT-thyrsus.com (Eric S. Raymond) | |
| To: | fedora-devel-list-AT-redhat.com | |
| Subject: | Goodbye, Fedora | |
| Date: | Wed, 21 Feb 2007 03:03:50 -0500 (EST) | |
| Cc: | lwn-AT-lwn.net, editors-AT-newsforge.com, sjvn-AT-vna1.com, editors-AT-linuxtoday.com |
After thirteen years as a loyal Red Hat and Fedora user, I reached my limit today, when an attempt to upgrade one (1) package pitched me into a four-hour marathon of dependency chasing, at the end of which an attempt to get around a trivial file conflict rendered my system unusable. The proximate causes of this failure were (1) incompetent repository maintenance, making any nontrivial upgrade certain to founder on a failed dependency, and (2) the fact that rpm is not statically linked -- so it's possible to inadvertently remove a shared library it depends on and be unrecoverably screwed. But the underlying problems run much deeper. Over the last five years, I've watched Red Hat/Fedora throw away what was at one time a near-unassailable lead in technical prowess, market share and community prestige. The blunders have been legion on both technical and political levels. They have included, but were not limited to: * Chronic governance problems. * Persistent failure to maintain key repositories in a sane, consistent state from which upgrades might actually be possible. * A murky, poorly-documented, over-complex submission process. * Allowing RPM development to drift and stagnate -- then adding another layer of complexity, bugs, and wretched performance with yum. * Effectively abandoning the struggle for desktop market share. * Failure to address the problem of proprietary multimedia formats with any attitude other than blank denial. In retrospect, I should probably have cut my losses years ago. But I had so much history with Red-Hat/Fedora, and had invested so much effort in trying to fix the problems, that it was hard to even imagine breaking away. If I thought the state of Fedora were actually improving, I might hang in there. But it isn't. I've been on the fedora-devel list for years, and the trend is clear. The culture of the project's core group has become steadily more unhealthy, more inward-looking, more insistent on narrow "free software" ideological purity, and more disconnected from the technical and evangelical challenges that must be met to make Linux a world-changing success that liberates a majority of computer users. I have watched Ubuntu rise to these challenges as Fedora fell away from them. Canonical's recent deal with Linspire, which will give Linux users legal access to WMF and other key proprietary codecs, is precisely the sort of thing Red-Hat/Fedora could and should have taken the lead in. Not having done so bespeaks a failure of vision which I now believe will condemn Fedora to a shrinking niche in the future. This afternoon, I installed Edgy Eft on my main development machine -- from one CD, not five. In less than three hours' work I was able to recreate the key features of my day-to-day toolkit. The after-installation mass upgrade to current packages, always a frightening prospect under Fedora, went off without a hitch. I'm not expecting Ubuntu to be perfect, but I am now certain it will be enough better to compensate me for the fact that I need to learn a new set of administration tools. Fedora, you had every advantage, and you had my loyalty, and you blew it. And that is a damn, dirty shame. -- Eric S. Raymond -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Posted Feb 21, 2007 15:43 UTC (Wed)
by ismail (subscriber, #11404)
[Link] (100 responses)
Posted Feb 21, 2007 16:17 UTC (Wed)
by markc (guest, #4419)
[Link] (82 responses)
Posted Feb 21, 2007 16:41 UTC (Wed)
by evgeny (subscriber, #774)
[Link] (62 responses)
Posted Feb 21, 2007 17:11 UTC (Wed)
by ofeeley (guest, #36105)
[Link] (47 responses)
So an alternative to dumping the whole thing is to fix whatever needs to be fixed and it seems like there's a serious effort going on to do that.
It's worth pointing out that for all the hysteria spread about RPM (and dependency resolvers/updaters built on top of it -- such as YUM), it mostly just works if you're just using it to stay current with updates of packages _within_ each release. The issue of doing live upgrades from one version of Fedora to another is something that it would be nice to work out http://fedoraproject.org/wiki/YumUpgradeFaq, but it's doable as long as you're willing to troubleshoot.
Posted Feb 21, 2007 17:19 UTC (Wed)
by evgeny (subscriber, #774)
[Link] (29 responses)
This FAQ doesn't answer the principal question: what key features are going to be in RPM that don't currently exist in deb/apt-get?? or cannot be added with a lesser efforts to deb??
Posted Feb 21, 2007 18:11 UTC (Wed)
by TwoTimeGrime (guest, #11688)
[Link] (7 responses)
Despite research and asking other debian sysadmins I could not find any options in dpkg to handle this.
Posted Feb 21, 2007 18:28 UTC (Wed)
by rfunk (subscriber, #4054)
[Link] (6 responses)
Posted Feb 21, 2007 19:38 UTC (Wed)
by sandy_pond (guest, #9734)
[Link]
http://in.sys-con.com/read/278818.htm
"One of the co-founders of the open source movement has become the member of the Freespire Leadership Board. Freespire is a community-driven, Linux-based operating system that gives users the option of combining free open source software with certain proprietary codecs, drivers and applications. Raymond, well-known as both a theorist and an advocate for the open source movement, joins twelve other Freespire Leadership Board members, composed of thinkers, business people, evangelists, and key members of the Linux community."
Posted Feb 21, 2007 20:52 UTC (Wed)
by muwlgr (guest, #35359)
[Link]
Posted Feb 22, 2007 0:25 UTC (Thu)
by TwoTimeGrime (guest, #11688)
[Link] (3 responses)
Thanks, but that highlights another think I dislike about debian. There are too many commands for package management. Now I have to remember dpkg, dpkg-query, and debsums along with all of their different options to manage my packages. At least with RPM systems there's a single command and options to remember which is just "rpm". Also, why isn't debsums' functionality built into the package management system by default? And why isn't debsums installed by default.
Posted Feb 22, 2007 3:24 UTC (Thu)
by drag (guest, #31333)
[Link] (2 responses)
Use wajig tool or the jig interface.
It's a python package management system that does it right. It basicly takes the functionality provided by all these little tools and utilities and makes a nice little user-friendly interface for it.
For example to backport a package from testing to stable you'd go like this:
wajig update
For instance I did that with OpenAFS server since the newer version in Testing was much better then what was aviable by default in stable. Took a whole 10 minutes to download, compile, then install the package.
Also I could of easily then taken the package and installed it on a bunch of machines.
The python bash-completion stuff works for it in testing. So if you go:
Or you can go:
Also it has intellegent handling of agruements with trying to do best effort match to your command to a certain extent.
will do the same thing.
Also you can do search through package names using tab.
And not only is the thing written in python and is convient to use.. it is QUICK. Very quick. Because the UI is in python were speed is not critical, but on the heavy calculating stuff it's all done by the little C programs that it's a front-end for.
That's the nice thing about Debian.
It's tools are small and contained. Just fast little utilities. Why have everything in some huge monolythic application? It just makes it buggy and difficult to use.
BTW this is the functionality you can get with wajig + debian package tools.
A lot of people prefer not to use front ends and use the tools directly, but I am lazy like that.
addcdrom -- Add a CD-ROM to the list of available sources of packages
""Also, why isn't debsums' functionality built into the package management system by default? And why isn't debsums installed by default.""
Probably because there is little need for it to be installed by default.
With Debian Etch signed packages are going to be used by default. This will ensure that they are not tampered with and are not corrupt. This is the most important reason why you'd need checksums...
There are lots of little things that make your life easier.
Like for instance 'deborphans'. Which uninstalls unused dependancies that may have been installed by a package you ended up removing later.
Or for example: localepurge.
Localepurge can be used to remove locales and localized man pages. It can save many hundreds of megs of disk space, maybe even a gig or two on a machine with a lot of stuff installed. Once you run it then it will automaticly be ran after installing or upgrading packages.
This stuff seriously kicks-ass. Most of the time the functionality of Yum is fine.
But Yum's slowness can be a huge pain. At my work I use a old 600mhz machine. A update using yum got interrupted halfway through becuase I ran out of disk space on / (my mistake).
I was there fixing it from 1 am to 5 am in the morning and the majority of the time was spent on waiting on yum to painfully go through it's motions. It was very very painfull to watch. Even with the -C switch it was painfull.
If it was Debian, and not CentOS:
would of fixed it in about 3 minutes.
Posted Feb 22, 2007 5:44 UTC (Thu)
by k8to (guest, #15413)
[Link]
There are some pretty simple glaring bugs with wajig that have gone unfixed for a lonnnng time. wajig show package fails if it is no longer downloadable but currently installed. apt-cache shows it fine. Huh?
Yeah I should submit a patch but sorry the other 15-odd patches I've submitted about other debian tools have come first.
Posted Mar 1, 2007 4:24 UTC (Thu)
by topher (guest, #2223)
[Link]
Definitely worth it, IMO. ;-)
Posted Feb 21, 2007 18:14 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
* Sane multi-lib support.
Posted Feb 21, 2007 23:07 UTC (Wed)
by proski (subscriber, #104)
[Link] (1 responses)
Posted Feb 22, 2007 8:08 UTC (Thu)
by bojan (subscriber, #14302)
[Link]
Posted Feb 21, 2007 18:37 UTC (Wed)
by foo (guest, #1117)
[Link] (5 responses)
E.g.:
# rpm -qf /etc/diameter/sunping.xml
Posted Feb 21, 2007 18:50 UTC (Wed)
by rfunk (subscriber, #4054)
[Link] (3 responses)
Posted Feb 22, 2007 15:00 UTC (Thu)
by foo (guest, #1117)
[Link]
Posted Feb 27, 2007 23:00 UTC (Tue)
by cdmiller (guest, #2813)
[Link] (1 responses)
dpkg -S /etc/passwd
Whereas:
Posted Feb 27, 2007 23:15 UTC (Tue)
by rfunk (subscriber, #4054)
[Link]
Posted Feb 21, 2007 19:16 UTC (Wed)
by fmarier (subscriber, #19894)
[Link]
To search in all packages (installed or not), first install the "apt-file" package, then run:
Posted Feb 21, 2007 19:48 UTC (Wed)
by vondo (guest, #256)
[Link] (6 responses)
rpm -qa --last
Give me a list of all the packages installed and order them by the last time they were updated.
Posted Feb 21, 2007 20:55 UTC (Wed)
by rfunk (subscriber, #4054)
[Link] (1 responses)
Posted Feb 21, 2007 22:06 UTC (Wed)
by jonabbey (guest, #2736)
[Link]
Okay, yeah, sorry, I've got nothing.
Posted Feb 22, 2007 5:46 UTC (Thu)
by k8to (guest, #15413)
[Link] (2 responses)
Now that dpkg keeps a log, someone could at least write such a thing, although I don't think one exists yet.
Posted Feb 22, 2007 14:41 UTC (Thu)
by rfunk (subscriber, #4054)
[Link] (1 responses)
Posted Feb 22, 2007 18:21 UTC (Thu)
by k8to (guest, #15413)
[Link]
Posted Feb 22, 2007 16:49 UTC (Thu)
by akumria (guest, #7773)
[Link]
eve:[~]% sudo tail /var/log/dpkg.log
perhaps?
Posted Feb 21, 2007 22:50 UTC (Wed)
by mrons (subscriber, #1751)
[Link] (3 responses)
yum localinstall somerandom.rpm
Posted Feb 22, 2007 0:55 UTC (Thu)
by mrons (subscriber, #1751)
[Link] (2 responses)
Just to expand on what this does, yum looks at what dependencies somerandom.rpm has and installs those with somerandom.rpm
somerandom.rpm does not have to belong to some {un}official repository.
So it's like "rpm -i" except that repositories are consulting to resolve dependencies.
Can I do something like "apt-get somerandom.deb" and have dependencies resolved for me?
Posted Feb 22, 2007 1:51 UTC (Thu)
by spotter (guest, #12199)
[Link]
if you
dpkg -i some.deb
that will try to install it, but it wont configure due to missing dependencies.
and
apt-get install -f
will then fix it as it will resolve the missing dependencies and configure everything.
Posted Feb 22, 2007 5:47 UTC (Thu)
by k8to (guest, #15413)
[Link]
Posted Feb 22, 2007 0:01 UTC (Thu)
by mmarq (guest, #2332)
[Link]
hmm ... better would be what misses in both, and or what can be improved in both.
well i remenber GoboLinux... its so damn easy that is hard to belive
But of course, many "commercial" apps already big on other environments, and that Linux would be needing to get a strong foot inside the workstation/desktop arena, arent going be be distributed in source code :(
But then again solutions appear like if by magic...
So, imho, what Linux need is a crossplatform installer capable of dealing with RPM and deb, and also capable of installing from source code... if only InstallJammer could implement that source code feature!... it would be perfect.
Posted Feb 21, 2007 22:59 UTC (Wed)
by markc (guest, #4419)
[Link] (16 responses)
RH/Fedora and spinoffs would gain a packaging system that already has the
Posted Feb 22, 2007 0:40 UTC (Thu)
by ofeeley (guest, #36105)
[Link] (15 responses)
What are those improvements that are desperately sought by us? Without the slightest trace of smartassedness I don't know what I'm missing. I have used yum for quite a while now and am very happy with it (I haven't bothered to look at pirut or pup although I did use pup's predecessor up2date for years). I've had a few problems but not many and nothing that I couldn't fix relatively easily.
"AND a huge swag of ready made packages"
The fedora repositories already have a huge swag of ready-made packages, just from within the officially blessed Core and Extras (which have now merged). If you add in unofficial repositories then it looks like there /may/ be a slight advantage of around 10% in terms of numbers of deb format packages as previously discussed: http://lwn.net/Articles/222681/
"(minus the ongoing transitional RPM package format nightmare, possibly for
What is this transitional nightmare? In all seriousness I've never heard of it.
Posted Feb 22, 2007 3:30 UTC (Thu)
by markc (guest, #4419)
[Link] (14 responses)
FWIW, I can only speak from personal experience. I inherited control of a
> The fedora repositories already have a
Nyah nyah, my deb fanboy thing is bigger than your rpm fanboy thing. The
> What is this transitional nightmare?
The current stability of the rpm system is because it has not been
The underlying point is that there is an ever so minute opportunity to
Posted Feb 22, 2007 5:42 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (10 responses)
There is a reason for not being able to upgrade a running system using "yum upgrade" - it's udev. It removes the old dev package during upgrade and your system dies.
Otherwise, it's a perfectly doable thing. You could even script it using kickstart. Done many upgrades of RHEL3 to RHEL4, completely unattended.
> One of the reasons this won't happen is because of rpm fanboyism, as you have clearly demonstrated, so "we" shall remain a fragmented group of fanboys.
See: http://kitenet.net/~joey/pkg-comp/
For instance, Debian packages cannot track file dependencies, something that distributions like Fedora rely on heavily. Actually, Fedora packaging policy is to prefer dependencies based on what the build process determines, rather than manual ones, which can be easily forgotten. Good or bad, that's the Fedora way...
Posted Feb 22, 2007 6:42 UTC (Thu)
by markc (guest, #4419)
[Link] (9 responses)
So in the case of a CentOS 3.6 -> 4.3 upgrade it would not be advisable
> See: http://kitenet.net/~joey/pkg-comp/[1]
11. Some people consider file dependancies a gross misfeature.
Posted Feb 22, 2007 7:52 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (8 responses)
Oh, it's absolutely advisable. Just use the upgrade process (anaconda runs that). You just can't do it while the system is hot.
> 11. Some people consider file dependancies a gross misfeature.
And, quite obiously, some don't.
Posted Feb 22, 2007 11:53 UTC (Thu)
by markc (guest, #4419)
[Link] (7 responses)
What is anaconda and would it be included in a CentOS 3.6 system ?
> You just can't do it while the system is hot.
There we go, the aspect of RPM management that is "desperately needed"[1]
[1] Refer to previous comments above.
Posted Feb 22, 2007 15:51 UTC (Thu)
by pizza (subscriber, #46)
[Link] (6 responses)
Stick the CD in, it boots up. That's anaconda.
> here we go, the aspect of RPM management that is "desperately needed"[1]
You're confusing "The RPM tools" with "The Debian Packaging Guidelines as implemented using the dpkg tools". Get your comparison straight.
> I have one box that has been up for 464 days and started with a Debian Sarge 2.6.12 devfs enabled kernel and now runs a Ubuntu Dapper udev enabled system, on the same kernel, without a reboot... the very excuse I was given for why upgrading from CentOS 3.6 to 4.3 was not possible. It seems that unless RPM based folks actually use a Debian based system they no not what they are missing out on.
"RPM-based folks" are apparently missing out on a lot of remote exploits and possible filesystem corruption!
I reboot my machines every 90 days (if not sooner due to power outages or whatnot) solely to install new kernels and run disk integrity checks.
I don't give two hoots about SERVER uptime; to me SERVICE uptime is all-important, and I achieve that with redundancy and performing test upgrades on non-critical systems in advance.
Posted Feb 22, 2007 16:41 UTC (Thu)
by markc (guest, #4419)
[Link] (5 responses)
Great, but not on a dedicated host 10,000 miles away.
> You're confusing "The RPM tools" with "The Debian
I think I'm comparing the use of any number of (unfamiliar to me) rpm
> "RPM-based folks" are apparently missing out on a
Some would argue it's not appropriate to have such file system checking
http://packages.debian.org/cgi-bin/search_packages.pl?key...
> I don't give two hoots about SERVER uptime; to me
Dare I suggest that if you used a Debian based distro you could go live
Posted Feb 22, 2007 17:18 UTC (Thu)
by pizza (subscriber, #46)
[Link]
>Some would argue it's not appropriate to have such file system checking
No; I was referring to the fact that you can't fsck a live filesystem, and that it's an unfortunate fact of life that filesystems are at best only as reliable as the disks they run on -- errors silently happen.
For me, periodic reboots serve two purposes -- Perform filesystem consistency checks, and install updated kernels (I am quite glad the 2.6.x.y series exists!)
It's more commonly known as scheduled preventative maintainence, and through the use of multiple physical systems, I avoid service downtime. (Even with virtualization, the host system needs occasional TLC too!)
> Dare I suggest that if you used a Debian based distro you could go live and stay live with less redundancy and pre-testing.
Been there, done that, been burnt by it. As I've alluded to many times in my posts here, it's the policies that you follow that ultimately matter. I discovered the hard way that using Debian didn't make things any simpler for me -- It just had a different set of quirks to watch out for.
Granted, this was a few years back, and Debian has addressed quite a few of the problems I had at the time... but as I've also said, if I don't see any tangible benefit to making a change, why bother?
Posted Feb 22, 2007 20:01 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (3 responses)
You missed the unattended upgrade bit above. The one with kickstart.
Let me repeat again. This particular limitation (of not being able to upgrade CentOS 3 to CentOS 4 while running) has nothing to do with RPM. It has to do with the fact that CentOS 4 (i.e. RHEL4) uses udev and CentOS 3 (i.e. RHEL3) uses a dev package. When dev gets removed by upgrading to udev, your system is hosed (you have nothing left in /dev).
Otherwise, I've done plenty of hot upgrades by doing "yum upgrade" on many different versions of Fedora.
> which is the point that ESR seems to have finally stumbled upon in the head article
He stumbled upon his on inability to manage his own system and/or ask others how to do it.
Posted Feb 22, 2007 20:15 UTC (Thu)
by loening (guest, #174)
[Link]
On a workstation that sits 300 miles away from me that I haven't seen in years.
Posted Feb 25, 2007 14:54 UTC (Sun)
by smurf (subscriber, #17840)
[Link] (1 responses)
You can mount a tempfs onto /mnt/whatever, create the bare essential device nodes there, move-mount that to /dev, and start up udev. (In fact, this is how a udev-based system boots in the first place.)
Total downtime for programs attempting to open /dev/null (or whatever): Zero.
Afterwards, if you do want to remove the old /dev-supplying package, well ... RPM has a --justdb option.
Posted Feb 26, 2007 4:27 UTC (Mon)
by bojan (subscriber, #14302)
[Link]
Well, if you run "yum upgrade", it is a fact that that's is what's going to happen: upgrade to udev will remove dev, which will remove all entries in /dev.
As you explained, it is not necessarily what needs to happen - but it does by default. So, unless you're prepared for some creative surgery (as per you explanation), you will get screwed.
Coming back the original question of supported upgrades from CentOS 3 to 4 (or RHEL 3 to 4), it is obviuos why this is not a recommeded thing to do - people don't normally want to recommend a complicated and risky process that would in the end require a reboot anyway (new kernel). RHEL packages were designed to be upgraded using the upgrade process, not "yum upgrade" (remember: RHEL 3 and 4 don't even ship yum, it's a CentOS addition).
You can find some more info here (search for udev):
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manu...
Note how you have to be on 2.6 kernel before starting this. CentOS 3 (i.e. RHEL 3) is based on 2.4 kernel.
Instead, one cuts a small kickstart file, starts an upgrade and after some minutes has a fully upgraded system with far less risk of stuffing things up.
Posted Feb 22, 2007 13:18 UTC (Thu)
by ofeeley (guest, #36105)
[Link]
If (as is probable from you calling it a VPS) it's a SWsoft/OpenVZ/Virtuozzo based VPS then the problem that you describe will definitely occur _if_ the hosting provider hasn't made the right templates available.
The only way that major upgrades across kernel versions can work with that sort of virtual server is if the kernel (and related infrastructure like the /dev/* stuff, glibc etc) that are pulled down when you do an update are matched by changes in the hypervisor.
The lack of upgradability of one CentOS version to another is more an issue of what your VPS hosting provider has made available than any limitation of rpm.
I don't know if the same limitations apply to other virtualisation techniques (Xen, kvm etc). I have experience of exactly the problem you're describing and it irritated me, but I blame the hosting company ;)
I can only assume that either you had pinned the kernel in your migration to/from various Ubuntu versions, or the hosting provider had templates available for all those versions.
Thanks for the rest of your clear and detailed answer.
Posted Feb 22, 2007 13:35 UTC (Thu)
by ofeeley (guest, #36105)
[Link] (1 responses)
It's a pity you ruined an interesting post with a personal attack. I don't think that asking for particular information as to the specific advantages of a system that I'm largely unfamiliar with, and correcting your mistaken impression that there are few rpm packages is fanboyism. I agree that a single packaging format would be useful in terms of reducing apparently duplicated effort.
Posted Feb 22, 2007 14:13 UTC (Thu)
by markc (guest, #4419)
[Link]
Thanks for pointing that out, I'll try and keep a more impersonal
>> FWIW, I can only speak from personal experience.
This was a dedicated host with a kernel that probably came default with a
>> I recently got a VPS with Debian 3.1 installed,
This was indeed a recent experience on a Virtuozo VPS with a 2.6.9 kernel.
>> I have one box that has been up for 464 days
This one, I think, is a custom rolled kernel with devfs compiled in and I
Posted Feb 21, 2007 17:41 UTC (Wed)
by drag (guest, #31333)
[Link] (5 responses)
From my limited understanding RPM is superior to Deb and it always has been.
The difference is the quality of the packages being made themselves. For a long time third party rpm files were created in a very ad-hoc/loose fasion and that reflected very badly when people tried them.
As for upgrading between releases by doing 'yum update' or 'apt-get update && apt-get dist-upgrade' is a difference of culture. In Debian this is valuable so they work hard to make sure it works, in Fedora they prefer just to let anaconda take care of the incompatabilities between releases.
I don't think either approach is wrong, although I think that Debian approach has advantages to end users. Then again Debian still hasn't gotten a stable release out and it's been a cronic problem so it's not like Debian's approach isn't without problems either.
Posted Feb 21, 2007 18:31 UTC (Wed)
by rfunk (subscriber, #4054)
[Link] (4 responses)
Posted Feb 21, 2007 22:29 UTC (Wed)
by drag (guest, #31333)
[Link]
Plenty of times I've had to cancel a update to a debian box halfway through and to recover from that only took a minute or so of work.
Posted Feb 22, 2007 20:40 UTC (Thu)
by eklitzke (subscriber, #36426)
[Link] (2 responses)
The only problems I have had with RPM have been circular dependencies (this not recently). This can, of course, occur with dpkg as well -- it's a problem that is symptomatic of poor packaging, not the package manager. OTOH, I have had issues with dpkg on a number of occasions. In particular, dpkg is not as strict about making sure that everything is going to work, and at least twice I have had failed dist-upgrades that broke the system, because half way through the upgrade dpkg panicked somewhere and left my system half broken. RPM is pretty paranoid in its transaction checks, and will not put you in this position.
Also: dpkg cannot install multiple versions of a package simultaneously. RPM can do that, portage can do that, I don't see why this huge feature has been neglected by the Debian community for years.
A long time Fedora user, I have recently been using Ubuntu because of a few big packages not present in Fedora that would be too onerous to maintain myself. I have been pretty pleased so far, but I still am not impressed with dpkg, especially given the niceties of RPM (and yum).
Posted Feb 23, 2007 7:52 UTC (Fri)
by drag (guest, #31333)
[Link] (1 responses)
I don't understand that and how that works.
In fact it caused major problems for me when I tried to use CentOS that I'd end up with multiple packages installed somehow with no easy way to get rid of them.
Say I have one program that depends on libfoo.3.2 and I have another program that depends on libfoo.3.5 with the libfoo project introducing incompatabilities in their lib files on minor numbers (As many projects do).
Does having multiple packages of libfoo installed automaticly make both programs work? I have no idea.
I mean I've been using Debian for years and I never ever had a desire to install two copies of the same program at the same time...
Posted Feb 23, 2007 23:28 UTC (Fri)
by eklitzke (subscriber, #36426)
[Link]
Posted Feb 22, 2007 8:58 UTC (Thu)
by gilboa (guest, #23856)
[Link] (5 responses)
We (as in the Fedora community/users/maintainers/core developers) do not need to justify -anything-.
Why do you even -care- if RedHat/Fedora/Mandriva/SUSE continue to use RPM? What is to -you-?
- Gilboa
Posted Feb 22, 2007 9:07 UTC (Thu)
by evgeny (subscriber, #774)
[Link] (4 responses)
Sure. It's such a nice hobby - reinventing the wheel. Especially a square wheel - so there must be two types of roads built parallel everywhere.
Posted Feb 22, 2007 9:25 UTC (Thu)
by gilboa (guest, #23856)
[Link] (3 responses)
I, for one, rather have my own choice, thank you.
Oh... and I for one, rather have an RPM based system then a deb system.
- Gilboa
Posted Feb 22, 2007 11:14 UTC (Thu)
by evgeny (subscriber, #774)
[Link] (2 responses)
Posted Feb 22, 2007 15:36 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
I'm having a hard time finding actual dates, but from what I can find out:
http://www.debian.org/doc/manuals/project-history/ch-deta...
dpkg was developed during 1994, but the first "public" release of debian with dpkg didn't happen until March 1995 -- 0.93r5.
http://fedoraproject.org/wiki/History
RPM was first used in RHL 2.0 Beta, publically released in the summer of 1995 but the immediate predecessor of RPM (RPP) became publically available in RHL 0.9 on October 1994. PMS was another package system that was used in the BOGUS distribution, and the brains behind RPP and PMS merged the best of both to create PM then RPM shortly afterwards.
So while technically Debian/dpkg was publically available before RHL/RPM, dpkg "wasn't already there" to be used when RHL1.0/RPP (and PMS) was released, nor while RPM was being developed.
Using your logic, "whoever decided to invent dpkg when RPP and PMS were already there should be similarly ashamed."
Posted Feb 22, 2007 18:00 UTC (Thu)
by evgeny (subscriber, #774)
[Link]
I really don't know whether RPP should count (i.e., how sophisticated it was), especially given that RPM wasn't backward compatible to it (then you can also count the primitive package management system used by Debian in 1993 and still get a one year off).
Posted Feb 25, 2007 8:50 UTC (Sun)
by rganesan (guest, #1182)
[Link] (1 responses)
I am a Debian developer but I am responding in defence of RPM, go figure ;-). First, apt-get did not pre-date RPM. Second, apt-get cannot be directly compared to rpm. rpm package equivalent is a deb package and rpm binary equivalent is dpkg utility. apt-get operates at a level higher than dpkg and automatically handles dependencies among other things. Connectiva ported apt-get to rpm and I prefer it over yum to administer the odd Redhat machine we have at work.
As a format, there's not really much to choose between rpm and deb. They both work well. In fact, there is a consistency in rpm command line that I like better than dpkg (for e.g. dpkg --listfiles and dpkg --contents vs rpm -ql and rpm -qlp). I also like the fact that source rpms are also rpms.
Why redhat invented yum when apt-get was already out there is still a mystery to me. However, yum or apt-get is still not the real issue. Even debian apt-get has trouble mixing and matching many repositories. I have had trouble installing some packages from Ubuntu universe/multiverse because the packages in those repositories don't meet the high standards of the code. The real issue is the quality of the underlying packages and the number of available packages.
And _that_ gentlemen is where Debian really shines. Debian is extremely anal about getting even the most trivial details in a package right. If you make the smallest typo/grammar mistake in your package description you get a bug. If you get your dependencies wrong, or doesn't handle upgrades correctly that's a severe bug. It's this attention to detail and the availability of all the packages in the core that makes Debian a winner.
Posted Feb 25, 2007 14:01 UTC (Sun)
by evgeny (subscriber, #774)
[Link]
> Connectiva ported apt-get to rpm and I prefer it over yum to administer the odd Redhat machine we have at work.
And so do I...
Posted Feb 21, 2007 16:41 UTC (Wed)
by k8to (guest, #15413)
[Link] (2 responses)
Posted Feb 21, 2007 19:02 UTC (Wed)
by malex (guest, #15692)
[Link] (1 responses)
Posted Feb 22, 2007 9:31 UTC (Thu)
by gilboa (guest, #23856)
[Link]
- Gilboa
Posted Feb 21, 2007 18:19 UTC (Wed)
by TwoTimeGrime (guest, #11688)
[Link]
Here's a list of how things are similar (debian <-> redhat):
debs are similar to rpms (the packages)
Posted Feb 21, 2007 18:23 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link] (11 responses)
I've been upgrading Red Hat and Fedora systems for the best part of a decade now, most recently I did the FC5 to FC6 upgrade just a few months ago on several of my PCs, and for most of that time clueless Debian fans have been telling me that it's impossible, even when I'm doing it right in front of them. I doubt that CentOS (being largely a Red Hat source re-spin) is missing this feature, but if it is that's no reason for Red Hat or Fedora users to think RPM is defective.
ESR isn't interested in Free Software, this latest "goodbye note" is more of the same from him, Fedora is cited as bad because it didn't include non-free components, even though Fedora was /explicitly/ about Free Software. As others have already noticed, ESR is hardly a disinterested party here, he's now on the board of directors of a corporation which explicitly wants to push proprietary codecs into desktop Linux.
Posted Feb 21, 2007 19:15 UTC (Wed)
by ofeeley (guest, #36105)
[Link] (10 responses)
Using YUM:
Using APT:
CentOS3 is a rebuilt from source version of RHEL3 (which in turn was based on RHL9), so it's probable that it can be done.
Posted Feb 21, 2007 20:24 UTC (Wed)
by mokki (subscriber, #33200)
[Link] (9 responses)
In each upgrade there were always 4-10 packages that prevented a clean upgrade. Usually they were external rpms that the official rpms were trying to replace but ended up conflicting, but there were also bugs in the dependency and especially in the replacement information in the official rpms.
I remember that at one upgrade I managed to break the whole rpm database (whose format has changed many a time) and had to basically install most rpms from scratch (but even then I did not do any upgrade/install from cd).
But claiming that rpm is poor because removing a library can break it is, while correct, what happens to all other package management systems.
I have also broken my gentoo installation by installing a broken glibc (which I luckily was able to recover from by running /bin/ash and copying from a still open nfs mount the required files). And gentoo packages never even try to warn you that the removed package would break half of the system.
My understanding of debs/apt has always been that it is a good technology, but that the culture behind the packaging is the only thing where the major differences comes from. On the other hand now that I had my first few experiences with debs a month ago while trying to compile them for N800 (arm target) I just could not believe that there really was no way of saying that I wanted to enable FPU instructions globally in CFLAGS but I had to patch each and every package separately. So it might be that the final debs are easy to use and work with, but the I found the building system for creating them very much lacking (or at least the documentation).
Posted Feb 21, 2007 21:24 UTC (Wed)
by bojan (subscriber, #14302)
[Link]
For me, it was RHL 5.0 all the way to FC6, at which point the hardware died. Pretty good run, if you ask me!
Posted Feb 22, 2007 6:09 UTC (Thu)
by k8to (guest, #15413)
[Link] (5 responses)
Programs that are already running already have the old library open, and new programs that depend upon the new library will open the new file. I have upgraded libc many times on Debian with nary a hitch. Deb addresses the all-at-once instant or nearly-instant changover between one coherent state and the next.
This _does not_ address the problem that a program may open a library late for whatever reason (SIGSTOP, dlopen), which usually results in a segfault but could be worse in some situations. It's plausible that this improvement might not look good from where you sit.
In practice though, Debian updates everything on the fly except the kernel and everything is fine. (A new kernel can of course be installed on the fly, but not loaded.)
Posted Feb 22, 2007 8:17 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (3 responses)
However, from the thread, I gather that ESR booted his box without that crucial library. And or course, the system was hosed.
Posted Feb 22, 2007 14:03 UTC (Thu)
by k8to (guest, #15413)
[Link] (2 responses)
Maybe it got fixed in the 5 years or so since I gave up SuSE, but I assumed it had not given your above comments.
I concur the problem here was rm important-file.
Posted Feb 22, 2007 14:05 UTC (Thu)
by k8to (guest, #15413)
[Link]
Posted Feb 22, 2007 20:07 UTC (Thu)
by bojan (subscriber, #14302)
[Link]
Going back to something like Red Hat Linux 7.2, this worked just fine. Upgraded glibc (remotely) many times. I honestly cannot remember before that...
Posted Feb 23, 2007 7:11 UTC (Fri)
by mokki (subscriber, #33200)
[Link]
As I said the only time I (almost) hosed my system was when I installed a broken glibc. After that you can no longer start any programs and you have to hope you have enough of needed terminals/other programs open that still refer to the old working glibc to recover the situation. The worst thing is that with a broken glibc no distribution tools can install/restore you to safe state again.
Posted Feb 22, 2007 9:53 UTC (Thu)
by tyhik (guest, #14747)
[Link] (1 responses)
It is. Static binary is indeed self-contained and to run it just the ABI-compatibility with the underlying kernel is needed.
Posted Feb 22, 2007 13:13 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Feb 22, 2007 9:00 UTC (Thu)
by gilboa (guest, #23856)
[Link]
... Which has -nothing- to do with RPM and everything to do with Anaconda. I'd really suggest you get the facts right -before- you start spreading FUD.
- Gilboa
Posted Feb 22, 2007 10:31 UTC (Thu)
by bojan (subscriber, #14302)
[Link]
The only thing this message rubs in is the fact that he made a mistake on his own system (after being properly warned), didn't know how to use the rescue disk, didn't have an up-to-date backup and then came to the list blaming everyone else for the problem he created. Very uncool.
> not possible to upgrade a CentOS 3 something system to the latest version without reinstalling from scratch.
Completely not true.
Posted Feb 22, 2007 12:43 UTC (Thu)
by nicku (guest, #777)
[Link]
There is no technical reason why rpm repositories cannot work as effectively as deb repositories.
The reasons are social and political. The Debian repositories are carefully tested to be consistent; dependencies are carefully worked through. The Debian repositories are remarkably complete, so there are few repositories that are not part of this cooperative effort to produce a coherent whole.
Red Hat repositories are not nearly as complete as Debian's, so there is a need for third party repositories such as dag, freshrpms, atrpms and all the rest. Red Hat employees considered their efforts to be of insufficient quality, so instead of encouraging them and working with them to reach a coherent, cooperative whole system, these other repositories were simply shunned.
Now I have many packages from these "rogue" repositories on my machines, and this makes the online upgrade from one version of Fedora to the next a rather time consuming effort. Not impossible, but much more difficult than The other problem is that the Red Hat/extras repositories have not been designed with on online If Red Hat would do the following, it would be wonderful:
Posted Feb 21, 2007 16:46 UTC (Wed)
by dmallery (guest, #635)
[Link] (6 responses)
eric's honesty and passion is a tradition we all need.
dave mallery
Posted Feb 21, 2007 19:12 UTC (Wed)
by ncm (guest, #165)
[Link] (3 responses)
Posted Feb 22, 2007 11:41 UTC (Thu)
by smitty_one_each (subscriber, #28989)
[Link] (2 responses)
Posted Feb 23, 2007 14:38 UTC (Fri)
by hummassa (subscriber, #307)
[Link] (1 responses)
Posted Feb 24, 2007 18:18 UTC (Sat)
by man_ls (guest, #15091)
[Link]
Posted Feb 22, 2007 9:13 UTC (Thu)
by gilboa (guest, #23856)
[Link] (1 responses)
- Gilboa
Posted Feb 22, 2007 9:15 UTC (Thu)
by gilboa (guest, #23856)
[Link]
Posted Feb 21, 2007 16:53 UTC (Wed)
by proski (subscriber, #104)
[Link] (8 responses)
Posted Feb 21, 2007 20:19 UTC (Wed)
by pizza (subscriber, #46)
[Link] (1 responses)
It would have been helpful if ESR had filed a bug report about the package that broke things, or indeed even said what FC release and repositories were in use -- or indeed, the package in question.
(This is particularly ironic given that ESR maintains the "how to ask smart questions" FAQ.)
Come on, he manually force-erased a critical system library. Of course things will break!
Posted Feb 23, 2007 14:46 UTC (Fri)
by hummassa (subscriber, #307)
[Link]
Posted Feb 21, 2007 21:34 UTC (Wed)
by ms (subscriber, #41272)
[Link] (2 responses)
You mean there was a time when CUPS was worse? The mind boggles!
Posted Feb 21, 2007 22:33 UTC (Wed)
by drag (guest, #31333)
[Link] (1 responses)
It's the support in Gnome or KDE (and other such applications) that sucks.
If printing in OS X is easy and printing in Linux is hard, then it's the applications in Linux that such and not the CUPS service.
since, you know, both OSes use the same CUPS software.
Posted Feb 21, 2007 22:48 UTC (Wed)
by rfunk (subscriber, #4054)
[Link]
Posted Feb 22, 2007 20:45 UTC (Thu)
by pipitas (guest, #22701)
[Link] (2 responses)
Our capable ESR did not realize at the time, that he used a frontend tool
But still, the criticism was taken up by Mike Sweet in a positive way, and
Which does not change my personal opinion about ESR being a guy who seems
Posted Mar 3, 2007 4:32 UTC (Sat)
by emj (guest, #14307)
[Link] (1 responses)
Try printing duplex on a Linux machine, from Acrobat Reader... ;-/
Posted Mar 3, 2007 6:26 UTC (Sat)
by bronson (subscriber, #4806)
[Link]
It's. an. utter. nightmare.
Sorry, that was theraputic. Clearly I still have a long way to go before I'm truly cured of my CUPS-induced trauma. :)
Posted Feb 21, 2007 22:37 UTC (Wed)
by daniels (subscriber, #16193)
[Link]
Posted Feb 21, 2007 15:49 UTC (Wed)
by rfunk (subscriber, #4054)
[Link] (1 responses)
Posted Feb 21, 2007 17:33 UTC (Wed)
by kirkengaard (guest, #15022)
[Link]
The crazy uncle of hacking complains about the grandfather of package management. Both feeble. News at 11.
Or,
ESR switches distributions! RedHat and Canonical shrug. News at 11.
Posted Feb 21, 2007 16:07 UTC (Wed)
by mgalgoci (guest, #24168)
[Link] (2 responses)
Posted Feb 21, 2007 16:22 UTC (Wed)
by marduk (subscriber, #3831)
[Link] (1 responses)
Posted Feb 22, 2007 13:17 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Feb 21, 2007 16:26 UTC (Wed)
by NigelK (guest, #42083)
[Link] (4 responses)
Posted Feb 21, 2007 16:31 UTC (Wed)
by sjj (guest, #2020)
[Link] (3 responses)
Posted Feb 21, 2007 16:42 UTC (Wed)
by k8to (guest, #15413)
[Link]
Posted Feb 21, 2007 23:33 UTC (Wed)
by frazier (guest, #3060)
[Link] (1 responses)
Posted Feb 24, 2007 15:52 UTC (Sat)
by job (guest, #670)
[Link]
It is, and that's the disturbing part the story. That may have
something to do with Raymond recently joining the Linspire board. Read this
newsletter from a little more than a month ago, especially point
number 10. Unethical to say the least. Eric S. Raymond, ladies and
gentlemen. It's a wonder he gets away with so much.
Posted Feb 21, 2007 16:59 UTC (Wed)
by nigelm (subscriber, #622)
[Link] (11 responses)
Maybe we could celebrate by disposing of fetchmail at the same time.
Posted Feb 21, 2007 19:00 UTC (Wed)
by malex (guest, #15692)
[Link] (10 responses)
Fetchmail still saves the day for many people. I know it does for me as
Posted Feb 21, 2007 20:18 UTC (Wed)
by DonDiego (guest, #24141)
[Link] (9 responses)
Posted Feb 21, 2007 20:38 UTC (Wed)
by rfunk (subscriber, #4054)
[Link] (8 responses)
Posted Feb 22, 2007 0:09 UTC (Thu)
by DonDiego (guest, #24141)
[Link] (5 responses)
Posted Feb 22, 2007 10:30 UTC (Thu)
by DonDiego (guest, #24141)
[Link] (4 responses)
Posted Feb 22, 2007 12:58 UTC (Thu)
by rfunk (subscriber, #4054)
[Link] (3 responses)
Posted Feb 22, 2007 15:03 UTC (Thu)
by ofeeley (guest, #36105)
[Link] (1 responses)
Posted Feb 23, 2007 6:03 UTC (Fri)
by DonDiego (guest, #24141)
[Link]
Posted Feb 23, 2007 6:16 UTC (Fri)
by DonDiego (guest, #24141)
[Link]
You may or may not have made fetchmail secure (BTW, ever tried fuzzing it?). If you did, congratulations. I'm quite confident you didn't reduce its size considerably, though.
Posted Feb 23, 2007 6:32 UTC (Fri)
by DonDiego (guest, #24141)
[Link] (1 responses)
CVE-2006-5974: Fetchmail was found to crash when refusing a message that was bound to be delivered by an MDA. This bug was introduced into fetchmail 6.3.5 and fixed in 6.3.6.
CVE-2006-5867: Fetchmail was found to omit TLS or send the password in clear text despite the configuration stating otherwise. This was a long-standing bug reported by Isaac Wilcox, fixed in fetchmail 6.3.6. There will be no 6.2.X releases to fix this bug in 6.2.X.
CVE-2006-0321: Fetchmail was found to crash after bouncing a message with bad addresses. This bug was introduced with fetchmail 6.3.0 and fixed in fetchmail 6.3.2.
CVE-2005-4348: Fetchmail was found to contain a bug (null pointer dereference) that can be exploited to a denial of service attack when fetchmail runs in multidrop mode. 6.2.5.5 and 6.3.1 have this bug fixed.
Posted Feb 23, 2007 6:52 UTC (Fri)
by rfunk (subscriber, #4054)
[Link]
Look, I couldn't care less if you prefer getmail over fetchmail. But if
Posted Feb 21, 2007 17:02 UTC (Wed)
by sbergman27 (guest, #10767)
[Link] (8 responses)
I'm sure that few to none will miss you.
Why is what this pompous, self important windbag says still considered news in the year 2007, anyway? ;-)
Posted Feb 21, 2007 17:25 UTC (Wed)
by tjc (guest, #137)
[Link] (7 responses)
Posted Feb 21, 2007 18:04 UTC (Wed)
by sbergman27 (guest, #10767)
[Link] (6 responses)
We do need to be going after the iPod generation.
But parting rants about distros are just so cliche!
And ESR is so full of himself that if you stuck him with a pin, I'm sure he'd burst! ;-)
-Steve
Posted Feb 22, 2007 4:05 UTC (Thu)
by marduk (subscriber, #3831)
[Link] (5 responses)
What exactly is meant by iPod generation? Is there a general consensus to what that means? Personally, when I saw that phrase I think of person A who buys something because person B has one and person A thinks person B is cool. But person B only bought it because he thinks person C is cool and he/she has one, etc. etc.
Is that who we need to be going after: the cool kids?
(Forgive my ignorance. I've never actually owned an iPod.)
Posted Feb 22, 2007 15:38 UTC (Thu)
by tjc (guest, #137)
[Link] (4 responses)
Or maybe it's people who fool around with their mp3 player while driving (preferably not behind me). Or maybe it's just marketing crap, and doesn't really mean anything.
Posted Feb 22, 2007 17:13 UTC (Thu)
by khim (subscriber, #9252)
[Link] (3 responses)
"iPod generation" is bunch of people who sold their freedom cheap. Why the hell free software guys should think about them at all - is beyond me. If they sold their freedom for cheap once - why do you think they'll fight for it the next time ? Sure - if everyone in new generation will sell their freedom for cool iPod the free software will become extinct, but to try to go after iPod generation is wrong way to fight for freedom...
Posted Feb 23, 2007 2:02 UTC (Fri)
by njs (subscriber, #40338)
[Link] (2 responses)
Shall we also ostracize everyone who has ever used a proprietary system? After all, only those who grew up with Linux, and have never used anything else, can truly be ideologically pure.
(This principle would, unfortunately, rather decapitate the free software movement. I don't think RMS even qualifies? He wasn't born believing in free software...)
Don't abandon 'em. Educate 'em. Some of 'em might be smarter than you think.
Posted Feb 23, 2007 11:14 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
Shall we also ostracize everyone who has ever used a proprietary system? After all, only those who grew up with Linux, and have never used anything else, can truly be ideologically pure. Huh ? Where have you got this idea ? Don't abandon 'em. Educate 'em. Some of 'em might be smarter than you think. This is the right idea. I don't have a problem with a guys who own iPod. As long as they know that all problems in Linux<->iPod interaction are not Linux fault, but Apple's fault - they are not hopeless but... they are not part of "iPod generation"!
Posted Feb 24, 2007 13:57 UTC (Sat)
by arcticwolf (guest, #8341)
[Link]
'"iPod generation" is bunch of people who sold their freedom cheap. Why the hell free software guys should think about them at all - is beyond me.'
Pretty clear, if you ask me.
Posted Feb 21, 2007 17:11 UTC (Wed)
by dowdle (subscriber, #659)
[Link] (3 responses)
To me, struggle is a sign of a healthy project... not some signal of doom.
Oh, wait... ESR switched to Ubuntu... the people leaching off of Debian. Same difference.
I agree with the person who said that dpkg isn't really techincally better than rpm... but Debian's strick packaging policy, bringing everything into the Debian fold of packages and maintaining it (rather than a large number of semi-common packages coming from third-party repositories)... has been a plus.
rpm's main problem is that there are indeed quite a few poorly built packages out there.
I don't exactly agree with ESR's opinion on adopting proprietary codecs. I prefer the situation where the end user can do that if they so choose... but the distro takes a stand to keep that stuff out officially.
Linspire has also opened up CNR for multiple distributions so I'm not sure there is something special about the Ubuntu/Freespire connection even if one were to totally buy into the "we must adopt proprietary codecs as an official part of the distro" mentality.
Just out of curiousity ESR, what's next? Should we all buy a copy of CrossOver Office and a license for Microsoft Office?
I must admit I'm a Fedora Core user for personal desktops and RHEL (Academic) and CentOS user on servers. I've used Debian and Ubuntu under some circumstances... but my decision was usually made for personal preference reasons rather than technical reasons. All distros share 95% (a made up number that sounds reasonable) of the same software so making a choice on preference isn't exactly illogical.
ESR, if you were unhappy and left, good for you. A small percentage of folks switch all of the time... and it is good to try out different distros. I'm glad we have all of this competition to keep the major players on their toes... a factor sorely missing somewhere else.
Posted Feb 21, 2007 18:34 UTC (Wed)
by foo (guest, #1117)
[Link] (2 responses)
Do you feel this is harmful to Debian in some way?
Curious, thanks.
Posted Feb 21, 2007 19:07 UTC (Wed)
by malex (guest, #15692)
[Link]
Posted Feb 22, 2007 6:54 UTC (Thu)
by ldo (guest, #40946)
[Link]
The poster said "leaching", not "leeching".
Posted Feb 21, 2007 18:04 UTC (Wed)
by JoeBuck (subscriber, #2330)
[Link]
Posted Feb 21, 2007 18:45 UTC (Wed)
by mheily (subscriber, #27123)
[Link] (21 responses)
An RPM spec file is basically comprised of four things: macros, tags, a list of files, and build/install/uninstall scripts. All of these things are jammed together in a single file that becomes bloated and hard to read -- especially when a lot of macros are used. The spec file is processed by a single, monolithic tool (/usr/bin/rpm) to produce a binary package.
By contrast, all Debian packaging information is kept in small, single-purpose files under the debian/ directory. The entire build process is controlled by a Makefile named debian/rules. The Makefile calls a number of small, single-purpose shell scripts provided by the 'debhelper' package to do the actual work. For example, if the package needs to install an entry in the system crontab, you add a line to the Makefile that calls the dh_crontab script, which merges the contents of debian/cron.d file into the system cron.d directory.
I'm not aware of an equivalent to debhelper in RPM, which means that packagers have to roll their own system-dependent scripts to do all the work that debhelper does for you.
Posted Feb 21, 2007 19:17 UTC (Wed)
by ncm (guest, #165)
[Link]
:-)
Posted Feb 21, 2007 19:54 UTC (Wed)
by pizza (subscriber, #46)
[Link] (18 responses)
RPM doesn't provide policy; the distribution-provided macros do. Where the macros don't provide policy, you need to look to the packaging guidelines.
Those "debain/Rules" helper scripts sound suspiciously like "system-dependent scripts to do all the work".
Note this is the same distinction as "the deb tools" vs "Debian's use of the deb tools".
Please, compare apples to apples. If you want to critique RH/Fedora's past packaging policies vs Debian's, fine. If you want to critique the featureset of the automagic-package-dependency-resolver-and-installers (aka apt and yum), fine. If you want to compare the technical capabilities of the dpkg format and tools versus the rpm format and tools, fine.
But don't go comparing a set of packaging policies to the tools used to implement said policies.
Oh, and finally, 'rpm' has not been monolothic for some time; the package builder (rpmbuild) uses quite a few modular tools, scripts, and macros to assemble packages.
Posted Feb 21, 2007 20:47 UTC (Wed)
by rickmoen (subscriber, #6943)
[Link] (8 responses)
Please, compare apples to apples. If you want to critique RH/Fedora's past packaging policies vs Debian's, fine. Well said, sir. In my view (as well), people making handwaving claims about merits of these two perfectly serviceable package formats should be gently lead to Joey Hess's indispensible "Comparing Linux/UNIX Binary Package Formats" page, and advised to please make certain their comments are informed ones.
Rick Moen
Posted Feb 21, 2007 21:43 UTC (Wed)
by midg3t (guest, #30998)
[Link] (7 responses)
Posted Feb 21, 2007 22:05 UTC (Wed)
by mheily (subscriber, #27123)
[Link] (1 responses)
The point I was trying to make is that the mechanism for defining and creating a DEB package is superior to the mechanism for defining and creating an RPM package. This is part of the reason why Debian packages are 'better' than RPM packages; the power and flexibility of the build system allows you to design better packages with less effort, which makes the end user's life (and now ESR's life, apparently) easier.
Posted Feb 22, 2007 16:28 UTC (Thu)
by pizza (subscriber, #46)
[Link]
There is no (major) technical reason why Debian couldn't switch to RPM, or Fedora switch to DPKG as the packaging format.
"Fedora on dpkg" will be indistinguishable from the current "Fedora on rpm". Likewise, "Debian on rpm" would be indistinguishable from the current "Debian on dpkg". As there is no technical benefit to doing so, there's no point in wasting everyone's time for a non-feature.
The "end-user's life" is "easier" precisely because of Debian's packaging policies. While the tools may have features to help facilitate said policies, the policies drive the tools, not the other way around.
Both Fedora's and Debian's strengths (and weaknesses!) lie in their policies, not their tools. Both distributions still have different goals, and their policies reflect those goals.
Posted Feb 21, 2007 22:12 UTC (Wed)
by ldo (guest, #40946)
[Link] (4 responses)
"Some people consider file depend[e]ncies a gross misfeature." But he doesn't explain why...
Posted Feb 21, 2007 22:42 UTC (Wed)
by branden (guest, #7029)
[Link] (1 responses)
An even better example is when file objects have the same name but are completely different applications. Think of firebird, for example.
Posted Feb 22, 2007 5:44 UTC (Thu)
by bojan (subscriber, #14302)
[Link]
Posted Feb 22, 2007 0:40 UTC (Thu)
by midg3t (guest, #30998)
[Link] (1 responses)
Posted Feb 22, 2007 15:55 UTC (Thu)
by macc (guest, #510)
[Link]
Posted Feb 21, 2007 21:24 UTC (Wed)
by mheily (subscriber, #27123)
[Link] (8 responses)
DEB uses a Makefile to control the package build process. DEB packages use a separate subdirectory to contain packaging-related files where each file has a specific purpose. DEB provides shell scripts (debhelper) that you can use in your Makefile rules.
RPM uses a custom packaging tool (rpmbuild) to control the package build process. RPM combines all packaging information into a single specfile. RPM provides macros which are expanded into Makefile rules.
What debhelper provides is convenience scripts so you don't have to write your own Makefile rules for common tasks. My crontab example showed how you could install and uninstall a crontab(5) entry by adding a single line to the debian/rules Makefile. Perhaps there are system-specific RPM macros you could use to do the same thing -- but I doubt it. More than likely, you will have to add a line to the %postinstall section that has a bunch of system-specific macros such as:
cp %{_sharedir}/%{pkgname}/cron.entry %{_sysconfdir}/cron.d/cron.daily/%{pkgname}
And then you have to add a corresponding line to %postremove saying:
rm %{_sysconfdir}/cron.d/cron.daily/%{pkgname}
Whereas in a DEB package, you simply add a Makefile rule that says:
dh_installcron
And the debhelper script generates the code necessary to install and uninstall the crontab entry. It takes care of the details, without the use of system-specific macros or directory layouts.
Makefiles combined with shell scripts are much more powerful and flexible than macros. AFAIK, the macros in RPM can only used for lexical transformation and substitution. Shell scripts are like functions and can take arguments on the command line, produce debugging output, call other shell scripts, etc.
And you're right -- the rpm(1) utility was so bloated in the past that the package building bits were broken out into a separate rpmbuild(1) executable. I still don't see the need for a special-purpose executable to manage the package build process when we already have a great, universal and time-tested tool for building software: make(1).
Posted Feb 21, 2007 22:35 UTC (Wed)
by sfeam (subscriber, #2841)
[Link]
So for deb you have to write a system-specific cron.d script, place it in
a directory, add a line to the Makefile. For rpm you add one one line to
the spec file. And from this you conclude that the deb process is more
convenient? OK.
To return to comparison of higher-level tools, I think any discussion of
rpm is incomplete without mention of the excellent urpm meta-tools that
let you manage queries, updates, and installations from multiple
repositories.
Posted Feb 21, 2007 22:48 UTC (Wed)
by branden (guest, #7029)
[Link] (6 responses)
An unpacked Debian source package -- or a brand-new package you've just created -- is as easy to build as "debian/rules build", and you don't need root.
If there's an easier approach than this, my RPM-savvy co-workers have not shared it with me.
Posted Feb 21, 2007 23:23 UTC (Wed)
by JoeBuck (subscriber, #2330)
[Link] (1 responses)
Posted Feb 22, 2007 18:22 UTC (Thu)
by branden (guest, #7029)
[Link]
Posted Feb 21, 2007 23:28 UTC (Wed)
by dwa (guest, #24604)
[Link]
Posted Feb 22, 2007 6:29 UTC (Thu)
by zlynx (guest, #2285)
[Link] (2 responses)
Posted Feb 23, 2007 11:27 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
This mechanism can be easily circumvented (homework: find at least 5 ways to do so) and thus again we are returning back to policy. Basically it's Windows approach: we'll forbid you to do this because you don't deserve to have control. Sad to have this misfeature in *nix tool...
Posted Feb 24, 2007 0:41 UTC (Sat)
by zlynx (guest, #2285)
[Link]
If you are determined to evade a proper source package, you can of course.
Posted Feb 21, 2007 20:43 UTC (Wed)
by dlang (guest, #313)
[Link]
besides just saying 'A depends on B' there is more flexibility to say things like 'A suggests B' or 'A recommends B'. I also think there is more flexibility in saying that 'A satisfies any dependancies that require B'
I think that yum layers some of this on top of .rpm, but it's available even with apt and dpkg with .deb
Posted Feb 21, 2007 21:29 UTC (Wed)
by dowdle (subscriber, #659)
[Link] (2 responses)
Is ESR's opinion that rpm should be staticly linked a valid one? I could have sworn there was an rpm-static at one time... but perhaps I'm confusing that with something else. I do recall one time I totally hosed libc on a box and with some staticly linked app (I thought rpm-static) I was able to fix it without rescue media.
Posted Feb 21, 2007 21:36 UTC (Wed)
by nigelm (subscriber, #622)
[Link] (1 responses)
I vaguely remember, from the days when I used to hang out on the rpm list, that there were some issues with the db libraries (probably version skew between the system ones and the static linked ones, with consequent explosions...).
Posted Feb 21, 2007 21:44 UTC (Wed)
by rfunk (subscriber, #4054)
[Link]
Posted Feb 21, 2007 21:31 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (9 responses)
- post rude rant about something that "doesn't work"
I was personally sick and tired of his "celebrity" tantrums on the list. So, this will be a welcome change.
Posted Feb 21, 2007 22:48 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (8 responses)
> I can tell you the library in question was libcom_err, and I think I deleted it when removing e2fsprogs-libs to get around a file conflict. But with rpm not working I couldn't reinstall the library. Boot failed, ssh/sshd failed -- I had to kluge with netcat and tar just to back up my files. It was horrible.
Posted Feb 21, 2007 23:26 UTC (Wed)
by JoeBuck (subscriber, #2330)
[Link]
Posted Feb 22, 2007 0:59 UTC (Thu)
by tetromino (guest, #33846)
[Link] (6 responses)
Posted Feb 22, 2007 1:14 UTC (Thu)
by bojan (subscriber, #14302)
[Link]
Yeah, users that remove (BY HAND) crucial files on their own system, should. Or, they can just use that recovery CD instead and put back the files. However, this is not for Big Hackers - only for us regular folks :-)
PS. Hint: read the thread. Mr. Celebrity whacked important files on his own system (after being warned by the system not to do it!), all while not having backup and then wrote his rude rant to everybody on the list.
Posted Feb 22, 2007 3:52 UTC (Thu)
by marduk (subscriber, #3831)
[Link] (4 responses)
Posted Feb 22, 2007 4:36 UTC (Thu)
by bojan (subscriber, #14302)
[Link]
Exactly. According to ESR himself, he wanted to upgrade a single package on the system. For this, one doesn't normally need backup (although it's always good to have it anyway). This upgrade attempt led to problems (the package management system told him there was going to be trouble). At this point, he should have asked questions on the list if he wasn't familiar with how to get himself out of trouble. Or even filed a bug. Or both. Or, if he was bent on doing it the "hacker way", he should have done the backup of his files at that point.
But, no. Instead, he pushed on by doing silly things (forceful removal of crucial libraries) and without backup. When the system finally got completely screwed (by his own doing), instead of using a recovery disk (in order words: it was still not too late!) and putting back the stuff he removed, he decided to flame the list. Where he blamed Fedora for the backup kludge that he needed to employ to save his files and described it as "horrible". At no point did it occur to him that he caused all this.
And to top it all off, this is not the first time he's done something like that. For instance, in December last year, there was a thread about "fedora-submit", which was initially written in a similarly arrogant manner. Along the lines of "my way or the highway". Of course, he never read any documentation or got himself familir with how things work in Fedora _now_. Many on the list pointed him in the right direction and after a few posts he accepted the advice and went to do his homework.
If he only asked about his problem before writing this rant, his problem would have been fixed with a lot less pain. And, maybe a few bugs would have been fixed too.
Posted Feb 22, 2007 6:27 UTC (Thu)
by k8to (guest, #15413)
[Link] (2 responses)
Sure on a production server, some minor differences in behavior might be catastrophic, but on a personal system, upgrading should leave me with a running system 100% of the time. I don't think this is unachievable, and I think it has generallly been achieved on most Linux distributions.
Posted Feb 22, 2007 7:31 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (1 responses)
If he didn't force it, nothing bad would happen. The system would be 100% usable. In other words, the software refused to performed an unsafe operation. As designed.
The real issue is that he found a packaging bug. He should have reported it. And he would get a proper workaround until it was fixed. So, the big issue he made out if this is nothing but a regular occurrence in any software - bugs.
Posted Feb 22, 2007 14:15 UTC (Thu)
by k8to (guest, #15413)
[Link]
Specific case: ESR removed a library and was sad.
General case: upgrading without removing random libraries like a bonehead should not be unsafe or even really potentially unsafe. It should work.
Posted Feb 21, 2007 21:57 UTC (Wed)
by job (guest, #670)
[Link] (3 responses)
Posted Feb 22, 2007 2:31 UTC (Thu)
by Nelson (subscriber, #21712)
[Link] (2 responses)
I could be a little more forgiving of ESR's cult of personality if he actually had contributed something useful in the last 10 years. Fedora is pretty damn transparent and you can go fix the damn code. CatB was a nice read back in the 20th century, what's new? What have you done for us lately? Maybe right edition 2 or something, Eric, things are a bit different now. Make youself useful some how.
Posted Feb 22, 2007 3:02 UTC (Thu)
by corbet (editor, #1)
[Link]
I debated with myself for some time before posting it. In the end I decided people were going to be talking about anyway, so I might as well put it up.
Posted Feb 23, 2007 0:58 UTC (Fri)
by wlach (subscriber, #23397)
[Link]
(speaking as someone who's not generally a fan of ESR)
Posted Feb 21, 2007 22:18 UTC (Wed)
by flewellyn (subscriber, #5047)
[Link]
I am seized with fits of apathy.
Posted Feb 21, 2007 23:02 UTC (Wed)
by Richard_J_Neill (subscriber, #23093)
[Link]
Having used both, I prefer apt, but it's a rather narrow margin, and perhaps more because I have a fast, modern machine running ubuntu, and a rather slow machine running Mandriva. The important thing is that the repositories should always be sane; in my experience, both Ubuntu and Mandrake are good at this (I refer to the stable, not devel releases). I don't recall ever having had a "dependency hell" issue with either distro in 5 years.
Posted Feb 21, 2007 23:23 UTC (Wed)
by b7j0c (guest, #27559)
[Link]
Posted Feb 22, 2007 0:23 UTC (Thu)
by yootis (subscriber, #4762)
[Link] (6 responses)
* Regularly sends "open letters", ostensibly to some party he disagrees with, but really to the public. These should either be privately directed to the intended party, or should be addressed to the public.
* Sends this drive-by flame about how he is switching to Ubuntu, without mentioning his financial relationships with Linspire, and by extension, Canonical.
* Makes a speech about how Linux should have nonfree codecs WITHOUT disclosing his financial relationship with a distro that specializes in that. It comes out some time later.
* Made up that stupid story about how Bill Gates insulted him at a conference once, and told it to lots of reporters.
* Threatens people with physical/gun violence (like Bruce Perens), thus hurting the cause of gun rights which he seems to care about.
* His obnoxious "travel rules" -- http://www.catb.org/~esr/travelrules.html
* Claims to speak for everyone in "his movement". Uses "we" a lot when making claims.
* Changed the statement in the jargon file that most hackers tend to be somewhat libertarian, which is probably true, whether you agree with that philosophy or not, to read that most hackers are Neoconservative, which is demonstrably false, again whether or not you agree with that philosophy. He did this because he HIMSELF had become a neoconservative and warblogger.
Posted Feb 22, 2007 1:17 UTC (Thu)
by ksoonson (guest, #2730)
[Link]
---> Could you please let me know details of this story? I couldn't find information on this.
Thanks very much.
Posted Feb 22, 2007 4:25 UTC (Thu)
by tseaver (guest, #1544)
[Link] (4 responses)
FWIW, his rules seem to boil down to:
- "I'm doing this for free, so *you* make it easy for me". As somebody
- "I don't have, nor want to be asked for, a credit card". He claims
If the demand for his appearances is high enough, those requirements should
Posted Feb 22, 2007 4:51 UTC (Thu)
by yootis (subscriber, #4762)
[Link]
I was referring more to these parts:
"If you want me to be in the air for longer than four hours, you have to pay for business or first class no matter who you are."
and
"...I expect you to pony up for business class or first class..."
His requests may or may not be reasonable. That isn't the point. It is the obnoxious, childish way that he states it.
In any case, this was the most minor of my examples.
Posted Feb 22, 2007 6:09 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (1 responses)
That's not the reason he states in the text. He states that: "Also please bear in mind that I do not have a credit card. This is deliberate; I value my privacy."
PS. When Fedora developers told him that they only want to ship free software, as a matter of principle, he got all cranky and declared them detached from reality and what not. Go figure...
Posted Feb 22, 2007 7:02 UTC (Thu)
by bojan (subscriber, #14302)
[Link]
Sorry :-(
Posted Mar 1, 2007 23:02 UTC (Thu)
by mikesalib (guest, #17162)
[Link]
I checked my email and politely explained to him that he *never* *told* us about his requirements. Furthermore, none of the other 30 attendees were so demanding. He acted churlish, but showed up anyway.
Apparently, I erred in not reading everything on his website. Regardless of the rules, the arrogance and self importance of expecting everyone to know them is mind boggling.
Posted Feb 22, 2007 0:33 UTC (Thu)
by ksoonson (guest, #2730)
[Link]
His points could have been accepted with better impression if he showed his opinion with polite attitude, explicit problem and his opinion on resolution.
Posted Feb 23, 2007 13:52 UTC (Fri)
by dark (guest, #8483)
[Link]
* Chronic governance problems.
* Persistent failure to maintain key repositories in a sane,
consistent state from which upgrades might actually be possible.
* A murky, poorly-documented, over-complex submission process.
* Allowing RPM development to drift and stagnate -- then adding
another layer of complexity, bugs, and wretched performance with
yum.
* Effectively abandoning the struggle for desktop market share.
* Failure to address the problem of proprietary multimedia formats with
any attitude other than blank denial.
Do we, honestly?Do we need this crap on LWN?
Yes, it all might help the RH/Fedora folks abandon rpm and standardize on Do we need this crap on LWN?
debs instead. This message from ESR really rubs it in. I've always used
deb systems and was only recently totally, I mean totally, blown away that
is was not possible to upgrade a CentOS 3 something system to the latest
version without reinstalling from scratch. That is absolutely pathetic in
the 21st century... all the more so since there is a much better
alternative. And to think the LSB depends on RPM!!!
Right. One may or may not share ESR's sentiments about [not] supporting non-free multimedia formats; however, the adherence to RPM is truly a shame for a distro. When the deb-versus-rpm flaming heats the zillionth time, one sees the RPM proponents trying to prove it's not less capable/reliable/... than deb. Even if true (though I've yet to see anybody stating it on oath) this would be absolutely insufficient to justify its existence - given that apt-get existed prior to RPM emergence.Do we need this crap on LWN?
Well, there seem to be a lot of changes already happening around RPM after a period of relative stasis: http://wiki.rpm.org/Docs/RpmOrgFAQDo we need this crap on LWN?
> Well, there seem to be a lot of changes already happening around RPM after a period of relative stasis: http://wiki.rpm.org/Docs/RpmOrgFAQDo we need this crap on LWN?
I'm a long-time Debian user but one feature in RPM that's not in the deb system is the ability to check the integrity of an installed package. With RPM I remember I could run with an option and it will see if all the packages files still were installed and would check the MD5SUM of each file against the package database. It was an easy way to check if files from a package were missing or corrupted. It helped me when once on a RH 7.x machine I accidentally ran "rm -rf /usr". I was able to find out what files were missing and then reinstall all of the relevant packages.Do we need this crap on LWN?
apt-get install debsums integrity checking
I don't think this has much to do with RPM vs debs as much as this link:integrity checking
I use debsums and I would like to note that .md5sums file is optional for .deb packages, unlike .rpms where I think md5sums are mandatory and could always be verified by rpm -V.integrity checking
> apt-get install debsums integrity checking
Well you don't have to remember anything.integrity checking
edit /etc/apt/sources.list and add the deb-src line for the repository.
wajig upgrade (to make sure everything is up to date_
wajig build-depend foo
wajig build foo
wajig install ./foo-blah-1.0.0.deb
wajig <tab><tab>
it will list all the commands it supports.
wajig list-commands
wajig listcommands
wajig List-Commands
auto-alts -- Mark the alternative to be auto set (using set priorities)
auto-clean -- Remove superseded deb files from the download cache
auto-download -- Do an update followed by a download of all updated packages
auto-install -- Perform an install without asking questions (non-interactive)
available -- List versions of packages available for installation
bug -- Check reported bugs in package using the Debian Bug Tracker
build -- Retrieve/unpack sources and build .deb for the named packages
build-depend -- Retrieve packages required to build listed packages
changelog -- Retrieve latest changelog for the package
clean -- Remove all deb files from the download cache
commands -- List all the JIG commands and one line descriptions for each
daily-upgrade -- Perform an update then a dist-upgrade
dependents -- List of packages which depend/recommend/suggest the package
describe -- One line description of packages (-v and -vv for more detail)
describe-new -- One line description of new packages
detail -- Provide a detailed description of package (describe -vv)
detail-new -- Provide a detailed description of new packages (describe -vv)
dist-upgrade -- Upgrade to new distribution (installed and new rqd packages)
docs -- Equivalent to help with -verbose=2
download -- Download package files ready for an install
file-download -- Download packages listed in file ready for an install
file-install -- Install packages listed in a file
file-remove -- Remove packages listed in a file
find-file -- Search for a file within installed packages
find-pkg -- Search for an unofficial Debian package at apt-get.org
fix-configure -- Perform dpkg --configure -a (to fix interrupted configure)
fix-install -- Perform apt-get -f install (to fix broken dependencies)
fix-missing -- Perform apt-get --fix-missing upgrade
force -- Install packages and ignore file overwrites and depends
help -- Print documentation (detail depends on --verbose)
hold -- Place listed packages on hold so they are not upgraded
init -- Initialise or reset the JIG archive files
install -- Install (or upgrade) one or more packages or .deb files
installr -- Install package and associated recommended packages
installrs -- Install package and recommended and suggested packages
installs -- Install package and associated suggested packages
install/dist -- Install packages from specified distribution
integrity -- Check the integrity of installed packages (through checksums)
large -- List size of all large (>10MB) installed packages
last-update -- Identify when an update was last performed
list -- List the status and description of installed packages
list-all -- List a one line description of given or all packages
list-alts -- List the objects that can have alternatives configured
list-cache -- List the contents of the download cache
list-commands -- List all the JIG commands and one line descriptions for each
list-daemons -- List the daemons that JIG can start/stop/restart
list-files -- List the files that are supplied by the named package
list-hold -- List those packages on hold
list-installed -- List packages (with optional argument substring) installed
list-log -- List the contents of the install/remove log file (filtered)
list-names -- List all known packages or those containing supplied string
list-orphans -- List libraries not required by any installed package
list-scripts -- List the control scripts of the package of deb file
list-section -- List packages that belong to a specific section
list-section -- List the sections that are available
list-status -- Same as list but only prints first two columns, not truncated
list-wide -- Same as list but avoids truncating package names
local-dist-upgrade -- Dist-upgrade using packages already downloaded
local-upgrade -- Upgrade using packages already downloaded, but not any others
madison -- Runs the madison command of apt-cache.
move -- Move packages in the download cache to a local Debian mirror
new -- List packages that became available since last update
news -- Obtain the latest news about the package
new-upgrades -- List packages newly available for upgrading
non-free -- List installed packages that do not meet the DFSG
orphans -- List libraries not required by any installed package
package -- Generate a .deb file for an installed package
policy -- From preferences file show priorities/policy (available)
purge -- Remove one or more packages and configuration files
purge-depend -- Purge package and those it depend on and not required by others
purge-orphans -- Purge orphaned libraries (not required by installed packages)
readme -- Display the package's README file from /usr/share/doc
recursive -- Download package and any packages it depends on
recommended -- Install package and associated recommended packages
reconfigure -- Reconfigure the named installed packages or run gkdebconf
reinstall -- Reinstall each of the named packages
reload -- Reload daemon configs, e.g., gdm, apache (see list-daemons)
remove -- Remove one or more packages (see also purge)
remove-depend -- Remove package and its dependees not required by others
remove-orphans -- Remove orphaned libraries (not required by installed packages)
repackage -- Generate a .deb file for an installed package
reset -- Initialise or reset the JIG archive files
restart -- Stop then start a daemon, e.g., gdm, apache (see list-daemons)
rpm2deb -- Convert a RedHat .rpm file to a Debian .deb file
rpminstall -- Install a RedHat .rpm package
rpmtodeb -- Convert a RedHat .rpm file to a Debian .deb file
search -- Search for packages containing listed words
search-apt -- Find local Debian archives suitable for sources.list
setup -- Configure the sources.list file which locates Debian archives
show -- Provide a detailed description of package [same as detail]
showdistupgrade -- Trace the steps that a dist-upgrade would perform
showinstall -- Trace the steps that an install would perform
showremove -- Trace the steps that a remove would perform
showupgrade -- Trace the steps that an upgrade would perform
size -- Print out the size (in K) of all, or listed, installed packages
sizes -- Print out the size (in K) of all, or listed, installed packages
snapshot -- Generates list of package=version for all installed packages
source -- Retrieve and unpack sources for the named packages
start -- Start a daemon, e.g., gdm, apache (see list-daemons)
status -- Show the version and available version of packages
status-match -- Show the version and available version of matching packages
status-search -- Show the version and available version of matching packages
stop -- Stop a daemon, e.g., gdm, apache (see list-daemons)
suggested -- Install package and associated suggested packages
tasksel -- Run the Gnome task selector to install groups of packages
toupgrade -- List packages with newer versions available for upgrading
unhold -- Remove listed packages from hold so they are again upgraded
unofficial -- Search for an unofficial Debian package at apt-get.org
update -- Update the list of down-loadable packages
update-alts -- Update default alternative for things like x-window-manager
update-pci-ids -- Updates the local list of PCI ids from the internet master list
update-usb-ids -- Updates the local list of USB ids from the internet master list
upgrade -- Upgrade all of the installed packages or just those listed
versions -- List version and distribution of (all) packages.
whatis -- A synonym for describe
whichpkg -- Find the package that supplies the given command or file
apt-get -f install
wajig is pretty fantastic. I wish it had become the standard instead of aptitude, and as a result was a bit more maintained.integrity checking
Just a note, if you enable the CentOS Extras repository on a CentOS 4.x box, there is an apt package available. You can enable it, use yum to install it, and then use apt to manage your packages from then on.apt in CentOS (was: integrity checking)
Okay, here's a key feature dpkg+apt is lacking that RPM has had for some time now:Do we need this crap on LWN?
Not quite. "yum install foo" will install both foo.x86_64 and foo.i386 and all dependencies for both. I expect it to install foo.x86_64 only. Apart from that, it's mostly OK.
Do we need this crap on LWN?
So, run "yum install foo.x86_64".Do we need this crap on LWN?
I prefer debs, too, but one thing I missDo we need this crap on LWN?
from my RPM days is the ability to query
which package owns a particular file.
ethereal-0.10.3-15.15
dpkg -S /etc/diameter/sunping.xml which package owns a file
Great, thanks!which package owns a file
Yeah but whats up with this?which package owns a file
dpkg: /etc/passwd not found.
rpm -qf /etc/passwd
setup-2.7.3-1mdv2007.0
That's a generated file rather than one installed from a package. (The base-passwd which package owns a file
package generates it, but I realize your point is about how to get that information.)
The easiest way I know to get that sort of information is to grep the files
in /var/lib/dpkg/info/.
To search in your installed packages:Do we need this crap on LWN?
dpkg -S /usr/lib/libxml2.so.2
apt-file update
apt-file search /usr/lib/libxml2.so.2
Since we've got deb experts reading this... The thing I miss from rpm days that I don't know how to do in deb/apt is:Do we need this crap on LWN?
I don't think a capability like that is built in, but try this: dpkg magic
ls -ltr /var/lib/dpkg/info/*.list | sed -e 's,^.*/\([^/]*\)\.list,\1,'
Ah, but what would Eric say about such an unfriendly, regressive, inward-focused approach to software design?dpkg magic
Until _quite_ recently this was completely impossible. Really. No records were kept at all.Do we need this crap on LWN?
the ls/sed hack I posted above works on Debian sarge, which (although current stable) dpkg log
isn't exactly "quite recent". No need for the dpkg log. And as far as I can see, recent
dpkg only keeps a log if you explicitly tell it to anyway. (Though I could be missing
something more recent.)
Buh, I didn't look at the criteria closely. I've often needed a log and found the 'most recent update' information was too lossy.dpkg log
Something like:Do we need this crap on LWN?
2007-02-22 06:33:35 status half-configured ttf-farsiweb 0.4.dfsg-6
2007-02-22 06:33:36 status unpacked git 4.3.20-10
2007-02-22 06:33:36 status half-configured git 4.3.20-10
2007-02-22 06:33:37 status installed git 4.3.20-10
2007-02-22 06:51:26 status half-configured dhcp3-server 3.0.4-13
2007-02-22 06:51:29 status half-configured ttf-farsiweb 0.4.dfsg-6
2007-02-22 06:52:35 status half-configured dhcp3-server 3.0.4-13
2007-02-22 06:52:37 status installed dhcp3-server 3.0.4-13
2007-02-22 06:52:37 status half-configured ttf-farsiweb 0.4.dfsg-6
How about:Do we need this crap on LWN?
> yum localinstall somerandom.rpmDo we need this crap on LWN?
not directly.Do we need this crap on LWN?
I use wajig as my do-everything debian package tool. It supports 'wajig install <packagename>' as well as 'wajig install ./a_package-3-3_i386.deb'Do we need this crap on LWN?
"" This FAQ doesn't answer the principal question: what key features are going to be in RPM that don't currently exist in deb/apt-get?? or cannot be added with a lesser efforts to deb?? ""Do we need this crap on LWN?
http://www.linux.com/article.pl?sid=07/02/09/1817227
http://installjammer.com/index.php?option=com_wrapper&...
But if the folks pushing RPM are considering improvements, after it's Do we need this crap on LWN?
development was almost abandoned for a few years, then it would be a major
plus for all of linuxdom if they wholesale dropped rpm altogether, adopted
the deb system, and then added what they feel might be missing to debs.
Then in one 1/2 year painful changeover period for rpm users (maybe, maybe
not) we'd have more than 75% of the linux distro universe using the same
package format and, also, Debians current huge and well organised
repositories would be INSTANTLY available to RH/Fedora users. That would
do more, in 6 months, to unify "linux" everywhere than all the talk and
LSBing we've had this century. Right now is such a golden opportunity for
RH/Fedora to make one of the most sensible changes, tht they have not even
contemplated, with the largest positive outcome for all concerned.
essential improvements they seek AND a huge swag of ready made packages
(minus the ongoing transitional RPM package format nightmare, possibly for
years). The dpkg/apt folks would gain a new swag of interested developers
and a new perspective on how to make debs even better than they are now.
In twelve months, at least three quarters of the linux universe would be
hugely better off. We would all have a major major league win and provide
an instant doubly powerful front to coerce both hardware and software
vendors to support linux (one pkg format to bind them all) and hedge
against any future M$ patent threats (they would no longer be able to pick
on just RH... well, it could help somewhat). Oh well, I can dream.
"RH/Fedora and spinoffs would gain a packaging system that already has theDo we need this crap on LWN?
essential improvements they seek"
years)."
> What are those improvements that areDo we need this crap on LWN?
> desperately sought by us?
CentOS 3.6 vhost and was told on some Plesk forums it was not possible to
upgrade to CentOS 4.3 (me gobsmacked). I recently got a VPS with Debian
3.1 installed, within 2 weeks I upgraded it to Ubuntu Dapper then on to
Debian Etch (v4) then back across to Ubuntu Feisty (because Debian doesn't
have a nanoweb package) with zero manual intervention. I was impressed and
would not dare to attempt an analogous path between Redhat and Fedora /
whatever. Maybe experienced RPM based folks are not "desperate" but I was
to upgrade a CentOS 3.6 system so it could run a later Plesk control panel
and, in my worldview, it was not going to be possible.
> huge swag of ready-made packages...
fundamental point was that if the RH/Fedora folks started using the deb
system then "we all" would have a much larger combined system than
separately. IMVHO if one or the other system was to be chosen as the base
to extend from then I would imagine most people would pick deb and drop
rpm. It would be interesting to see an open vote on such a decision.
upgraded or hacked on for a few years. Once the developers start coming
out with improved betas I can imagine there will once again be "upgrade
problems". Making a clean break to the deb system *may* be less painful
than ongoing rpm packager updates.
have one single MAJOR packaging format for linux systems and *if* it was
vaguely possible for one of the 2 major players to drop their current
format and go with the other then that opportunity is/was *now*. The
combined resources of both systems would present, essentially, a single
unified linux package system for both commercial and open providers and
such a move would become the single most notable advancement for linux
this decade. One of the reasons this won't happen is because of rpm
fanboyism, as you have clearly demonstrated, so "we" shall remain a
fragmented group of fanboys.
> I inherited control of a CentOS 3.6 vhost and was told on some Plesk forums it was not possible to upgrade to CentOS 4.3 (me gobsmacked).Do we need this crap on LWN?
> There is a reason for not being able to upgradeDo we need this crap on LWN?
> a running system using "yum upgrade" - it's udev.
for an inexperienced rpm user to upgrade a remote vhost.
> For instance, Debian packages cannot track
> file dependencies, something that distributions
> like Fedora rely on heavily.
> So in the case of a CentOS 3.6 -> 4.3 upgrade it would not be advisable for an inexperienced rpm user to upgrade a remote vhost.Do we need this crap on LWN?
> Oh, it's absolutely advisable. Just use theDo we need this crap on LWN?
> upgrade process (anaconda runs that).
and equally denied by those who know not. The fairly radical cross distro
upgrade procedure I describe earlier did not require a reboot and no
service was down for more that 30 seconds max. That, to me, is an
essential part of running SERVERS where uptimes rule and why I have always
used Debian based systems. I have one box that has been up for 464 days
and started with a Debian Sarge 2.6.12 devfs enabled kernel and now runs a
Ubuntu Dapper udev enabled system, on the same kernel, without a reboot...
the very excuse I was given for why upgrading from CentOS 3.6 to 4.3 was
not possible. It seems that unless RPM based folks actually use a Debian
based system they no not what they are missing out on.
> What is anaconda and would it be included in a CentOS 3.6 system ?Do we need this crap on LWN?
and equally denied by those who know not.
> Stick the CD in, it boots up. That's anaconda.Do we need this crap on LWN?
> Packaging Guidelines as implemented using the dpkg
> tools". Get your comparison straight.
tools with apt-get where the later seems to have the edge... which is the
point that ESR seems to have finally stumbled upon in the head article.
> lot of remote exploits and possible filesystem corruption!
built in to a package management system.
> SERVICE uptime is all-important, and I achieve
> that with redundancy and performing test upgrades
> on non-critical systems in advance.
and stay live with less redundancy and pre-testing. My example of swapping
between 4 deb based distros on an el-cheapo commodity $15/month VPS
without losing any downtime was intentional. No redundancy or testing
needed, just good software, especially on the barest metal.
>> "RPM-based folks" are apparently missing out on aDo we need this crap on LWN?
>> lot of remote exploits and possible filesystem corruption!
>built in to a package management system.
> Great, but not on a dedicated host 10,000 miles away.Do we need this crap on LWN?
Speaking of remote upgrades with RPM. I personally have doneDo we need this crap on LWN?
RH8->RH9->FC1->FC2->FC3->FC4->FC5->FC6
So please enlighten us poor souls who have *no*idea* why you'd need to "clean out" /dev when moving to an udev-based system. Why not leave the old package-supplying-/dev-nodes installed?dev => udev
> why you'd need to "clean out" /dev when moving to an udev-based systemdev => udev
"I recently got a VPS with DebianDo we need this crap on LWN?
3.1 installed, within 2 weeks I upgraded it to Ubuntu Dapper then on to
Debian Etch (v4) then back across to Ubuntu Feisty (because Debian doesn't
have a nanoweb package) with zero manual intervention."
"One of the reasons this won't happen is because of rpmDo we need this crap on LWN?
fanboyism, as you have clearly demonstrated, so "we" shall remain a
fragmented group of fanboys."
> It's a pity you ruined an interesting post with a Do we need this crap on LWN?
> personal attack.
perspective in the future. I don't often get involved in threads like
this. To clarify the kernels involved in the personal experiences I
quoted...
>> I inherited control of a CentOS 3.6 vhost and was
>> told on some Plesk forums it was not possible to
>> upgrade to CentOS 4.3 (me gobsmacked).
CentOS 3.6 install.
>> within 2 weeks I upgraded it to Ubuntu Dapper then
>> on to Debian Etch (v4) then back across to Ubuntu
>> Feisty (because Debian doesn't have a nanoweb
>> package) with zero manual intervention.
>> and started with a Debian Sarge 2.6.12 devfs
>> enabled kernel and now runs a Ubuntu Dapper
>> udev enabled system, on the same kernel,
>> without a reboot.
happened to include CONFIG_SYSFS=y. Ah, I see, if I rebooted on this same
kernel then I may have problems, however, the kernel and grub settings
installed by Ubuntu Dapper would bring up a newer 2.6.15 kernel.
I don't think that it's a issue with RPM vs deb for package format technical superiority.Do we need this crap on LWN?
While I agree that the main difference is culture and care, I disagree that RPM is Do we need this crap on LWN?
technically superior. dpkg has the "partially-installed" status, preventing the database
corruption that RPM is famous for.
Ya that is nice.Do we need this crap on LWN?
FWIW...Do we need this crap on LWN?
""Also: dpkg cannot install multiple versions of a package simultaneously. RPM can do that, portage can do that, I don't see why this huge feature has been neglected by the Debian community for years.""Do we need this crap on LWN?
Normally this is used for things that aren't libraries. For example, you might want to have multiple kernels installed, multiple versions of MySQL, multiple versions of Python, etc. I think if you were careful you could do this with libraries as well, but I'm not sure how intelligent RPM would be wrt overwriting symlinks. As it stands, Debian based distributions include the package version as a component of the package name, to get around the limitation. This is why, for example, on Ubuntu there is currently a python2.4 and python2.5 package. In an RPM based distribution there would just be a bunch of python packages in the same repository, and by default the newest one is installed -- if you need an older version and it is in the repository, it can be pulled in by another package's dependencies, or you can specify the version you want to install at the command line. This is a useful feature, and there are yum extensions (e.g. installonlyn) that use it in interesting and creative ways.Do we need this crap on LWN?
... ARGH!Do we need this crap on LWN?
You feel that deb is superior? You believe that RPM should be taken behind the shed and shot? Good for you. Use Debian! -Nobody- is forcing your hand.
> We (as in the Fedora community/users/maintainers/core developers) do not need to justify -anything-.Do we need this crap on LWN?
... Hey, while you're at it.Do we need this crap on LWN?
Why do we need vim and emacs?
Evolution, kmail and thunderbird?
Firefox, Epiphany and Konq?
GNOME, KDE, E17 and XFCE?
BSD and Linux?
If you rather have a closed-we-decide-what's-good-for-you-and-you-have-nothing-to-say-about-it-process, I'd suggest you switch to Windows. Microsoft always knows what's best for you.
(especially on x86_64) - but this is my choice to make.
You confuse the choice of _applications_ with multiple incompatible _standards_. The latter is devil - which everyone in a sane mind knows (besides MS and, apparently, you). "Firefox, Epiphany and Konq" are fine as far as they don't invent HTML extensions. IE, on the other hand, is known for doing exactly that. And so whoever decided to invent RPM when deb was already there, should be similarly ashamed. I don't believe RH will switch to deb now - it's too late, but a gross mistake remains a gross mistake. And I strongly believe the reason was only to distancing from Debian in any possible way. At a much later time, when the choice was whether to go yum or apt-rpm, they picked the inferior (can't say now, but certainly by then) yum. Same reason.Do we need this crap on LWN?
> And so whoever decided to invent RPM when deb was already there, should be similarly ashamed.deb "wasn't already there" to be used.
> So while technically Debian/dpkg was publically available before RHL/RPM, dpkg "wasn't already there" to be used when RHL1.0/RPP (and PMS) was released, nor while RPM was being developed.deb "wasn't already there" to be used.
> Even if true (though I've yet to see anybody stating it on oath) this Do we need this crap on LWN?
> would be absolutely insufficient to justify its existence - given that
> apt-get existed prior to RPM emergence.
OK, thanks for clarifications. I stand corrected.Do we need this crap on LWN?
While I think debs are better too, I don't think the kind of reliability you're comparing here is really deb's prowess really. It's more a matter of lots of slogging through hammering out solid policy and enforcing it.Do we need this crap on LWN?
You got it nailed. Compare the debian-mentors mailing list's tradition of Do we need this crap on LWN?
taking apart every presented package to the uncharted eons of badly made
rpms and it becomes clear that quality control is what makes Debian
upgrades so painless.
A. Official Fedora repositories (Core, Updates, Extras) share the same mentor's like program. (AKA: Package review and sponsor process).Do we need this crap on LWN?
B. Once you go 3rd party (unofficial repos), it's your own ass to fry. (BTW, last time I tried to install freenx on my Etch system [from a 3'rd party repo] I almost ended up with a dead Debian system - Somehow you don't see me blaming deb for my own mistakes.)
You are confusing the apt system with debs. Debs are the packages just like RPMs are packages. Debian-based distros use the apt tools to resolve dependencies. RPM people use a program called yum to resolve dependencies.Do we need this crap on LWN?
dpkg (the program) is similar to rpm (the program)
apt is similar to yum
"I've always used deb systems and was only recently totally, I mean totally, blown away that is was not possible to upgrade a CentOS 3 something system to the latest version without reinstalling from scratch."Do we need this crap on LWN?
I've only done FC4->FC5 and then FC5->FC6, but a few people seem to report going from much earlier versions:Do we need this crap on LWN?
http://www.brandonhutchinson.com/Upgrading_Red_Hat_Linux_...
http://www.silug.org/lists/silug-discuss/200405/msg00000....
I have done upgrades from RH 7.1->7.2->7.3->8->9->FC1->FC2->FC3->FC4 until the hardware failed a year ago. I used whatever was the best method available at time, rpm --freshen, up2date or yum upgrade.Do we need this crap on LWN?
As far as I know it is not possible to create a static binary that does not somehow depend on the glibc (or some other critical library).
> RH 7.1->7.2->7.3->8->9->FC1->FC2->FC3->FC4Do we need this crap on LWN?
Realistically you can swap out libraries that are fundamental.Do we need this crap on LWN?
AFAIK, this is a kernel feature. As long as there is something using an inode, the kernel won't let go. So, existing programs are OK and new ones pick up the new stuff. Upgrading things like glibc is safe with RPM in my experience (although you can have unexpected trouble if you update components of X11 while running yum from an X11 session, as X11 may die on update).Do we need this crap on LWN?
Right, the inode-based filesystem makes this (mostly) transparent. But rpm's approach to file updates (used to) prevent the update of base libraries from being achievable on running systems.Do we need this crap on LWN?
Oh, and I've certainly updated X from 6.8 through 7.1 while running it without a hitch. I'm still convinced dpkg handles this slightly better. But it may just be prejudice on my part.Do we need this crap on LWN?
> But rpm's approach to file updates (used to) prevent the update of base libraries from being achievable on running systems.Do we need this crap on LWN?
Swapping of glibc at runtime works nicely on all distributions.Do we need this crap on LWN?
"As far as I know it is not possible to create a static binary that does not somehow depend on the glibc (or some other critical library)."Do we need this crap on LWN?
... unless it does name (service, network...) resolution, in which case you need the nss libraries from the version of glibc the program was built with.Do we need this crap on LWN?
"CentOS3 to 4.4"Do we need this crap on LWN?
> This message from ESR really rubs it in.Do we need this crap on LWN?
Silly rpm vs deb flame war
That is absolutely pathetic in
the 21st century... all the more so since there is a much better
alternative. And to think the LSB depends on RPM!!!
apt-get dist-upgrade.yum upgrade as a high priority objective.
(See The Sneetches and Other Stories by Dr Seuss).
yum upgrade work well on systems using packages from only Red Hat/Fedora repositories
yes we do.Do we need this crap on LWN?
When you find some scruples let me know. This guy is no friend to Free Software.Do we need this crap on LWN?
I submit that real power is the blend of idealism from the "RMS" viewpoint, coupled with the pragmatism of the "ESR" viewpoint.Do we need this crap on LWN?
Can one not appreciate both? Why force a logical OR on me, when an AND works fine?
s/OR/XOR :-) He, he
You mean, like saying this
ANDing
The relationship between the Free Software movement and the Open Source movement is [...] (w)e disagree on the basic principles, but agree more or less on the practical recommendations. So we can and do work together on many specific projects. We don't think of the Open Source movement as an enemy. The enemy is proprietary software.
instead of this?
The culture of the project's core
group has become steadily more unhealthy, more inward-looking, more
insistent on narrow "free software" ideological purity, and more
disconnected from the technical and evangelical challenges that must
be met to make Linux a world-changing success that liberates a
majority of computer users.
Take your pick.
It's all nice and dandy... as long as you ignore the fact that ESR already "left" Fedora close to a year ago. [1]Do we need this crap on LWN?
Forgive my bluntness, ESR is a publicity whore; his attacks against CUPS, Fedora (among others - easily found by a simple Google) were mostly composed baseless ranting.
[1] http://lwn.net/Articles/178294/
Wrong link.Do we need this crap on LWN?
http://lwn.net/Articles/178285/
I remember ESR issued a similar tirade against CUPS. CUPS got better as a result. Let's hope Fedora would get better too.
Do we need this crap on LWN?
Unfortunately, while the CUPS rant had some tangible meat to it, this one seems to be just a rant. It's also inconsistent with many of his previous public statements about Fedora.Do we need this crap on LWN?
> the CUPS rant had some tangible meat to it Do we need this crap on LWN?
No it did not.
It was the same problem -- the guy didn't want to use the right tool for
the job. In the case of CUPS, I have not encountered a printer that didn't
show up correctly in the "Printers" KDE control panel applet for a long
time. Plug it in, fire kcontrol, install the cups drivers, print away --
including network printers.
I am a Kubuntu-using guy, but ESR's rants are normally tangible-meat-free.
:-)
> I remember ESR issued a similar tirade against CUPS. CUPS got better as a result.Do we need this crap on LWN?
CUPS is fine.Do we need this crap on LWN?
Actually I've run into more problems with CUPS in OS X than in KDE. Though that's Do we need this crap on LWN?
because Mac people are more willing to install random binary "printer driver" software
from the printer CD.
And I absolutely hated CUPS until I started using it through KDE's print system.
Yes, I also remember his tirade directed against CUPS.Do we need this crap on LWN?
to CUPS that was not part of CUPS itself. That frontend (called s.th.
like "rh-print-manager" or similar, can't remember exactly) was what made
his life so bad that he even quoted his Aunt Tillie... And that very
RedHat/Fedora frontend was the reason for most of the bad PR CUPS received
at the time (Native CUPS tools and its default configuration would have
handled easily the requirements ESR had for his home printing...).
Mike introduced several changes and improvements into CUPS 1.2.x because
of that.
to love publicity around his person more than anything else...
But the printer dialogs on Linux desktops sucks, maybe it isn't CUPS fault but blame has to be lain some where.Do we need this crap on LWN?
Well, I blame CUPS for thinking to this day that "client-error-forbidden" is a perfectly adequate error message. The error messages that CUPS prints out have to be about the worst in the entire industry. The only solution is to turn on debugging and then dig through an 2 MB trace (that includes all web/CGI traffic too) trying to see what went wrong.Do we need this crap on LWN?
No, since it only enourages him and makes him feel like he matters, and honestly, I wish people would stop doing that.Do we need this crap on LWN?
From the headline I assumed that he was saying goodbye to the whole Linux (and Open ESR's goodbye note
Source) community, since he's kept a low profile for the past few years.
Turns out he's just catching up to what many of us Debian/Ubuntu users figured out long
ago.
Yeah, I though that myself. Pity.ESR's goodbye note
I for one welcome Eric's future contributions to the Ubuntu community. Fedora doesn't need him :)Re:
I wonder: had written a "Goodbye, Slackware" back in 1998 would anybody care? Probably not. So why is one person's switching of distros of concern to the community in general?ESR's goodbye note
Well, some of the responses (such as the one-liner pointing him to his own smart-questions FAQ) were extremely amusing.ESR's goodbye note
This wouldn't be Freespire's ESR running down a major competitor, now would it?ESR's goodbye note
Well, he's plugging Ubuntu here, not Freespire ;-)ESR's goodbye note
A major partner, nonetheless.ESR's goodbye note
from the article:
ESR's goodbye note
Canonical's recent deal with Linspire, which will give
Linux users legal access to WMF and other key proprietary codecs, is
precisely the sort of thing Red-Hat/Fedora could and should have taken
the lead in.
That seems like a plug for Linspire to me.
-Brock
ESR's goodbye note
I have to say, I just don't see the downside... well unless you are an Ubuntu user.Truely a day to celebrate
Hey, hey, hold your axe mister :)Truely a day to celebrate
kmail was crashing and mangling my inbox on the Exchange server I must use
for work email and fetchmail/procmail is painless and bulletproof so far.
You may wish to try getmail to replace fetchmail. Works beautifully, is smaller, easier to configure and does not have a fresh exploit every other week.Truely a day to celebrate
Fresh exploit every other week? The only security issues in fetchmail in at least the past getmail
year or so have been one or two related to whether or not the connection is encrypted,
and one denial-of-service vulnerability. (fetchmail 6.2.x had lots of vulnerabilities, but that
version has been dead for a long time.)
There's also a lot of knowledge about weird POP/IMAP servers in the fetchmail code.
BTW, ESR hasn't had anything to do with fetchmail in a few years; I took maintainership
from him in about mid-2004 after he'd let it stagnate for a while, and these days Matthias
Andree does almost all of the work.
I'm too lazy to look up the details but fetchmail made regular appearances in the LWN security section back when I still used it. Whether current versions are any better I don't care at all - I've found a better replacement.getmail
Read this week's security page, fetchmail makes a double appearance ...getmail
Yes, on exactly the issues I mentioned. fetchmail security
Let me know when you figure out the difference between "New
Vulnerabilities" and "Updated Vulnerabilities".
Besides which, programs with unreported vulnerabilities are probably just programs not receiving scrutiny and patching from a good maintainer ;)fetchmail security
No. Although the examples are admittedly few there are securely designed and implemented programs that don't reveal vulnerabilities even under close scrutiny. vsftpd comes to mind.fetchmail security
I'm apparently not making myself clear here .. I don't give a damn about new versions ever since I found a replacement that I consider superior in every respect (and no, I don't care about supporting obscure broken servers). I had grown discontent with the size of fetchmail and its man page for some time already. What then finally made me look for a replacement was fetchmail showing up on the security page every other week...fetchmail security
Right on the fetchmail homepage I find not one or two but four advisories from the last year or so, all of which apply to 6.3.x:
fetchmail vulnerabilities in the last year or so
This is getting ridiculous. I said one of two DoS and one encryption fetchmail vulnerabilities in the last year or so
issue, in the past year or so. You listed one encryption issue from
2006, two DoS from 2006, and a DoS from 2005. It's now 2007. By my
count the situation is exactly as I said, but if you want to include the
2005 DoS in there then you can have a cookie or whatever for counting
three DoS instead of 1-2.
you're going to push getmail or criticize fetchmail, please do it with
something approximating the truth. Fetchmail's post-ESR security record
of a handful of low-risk vulnerabilities is far better than your
characterization of "a fresh exploit every other week."
Good Bye, Eric. Adios, au revior, and auf weidersehen.ESR's goodbye note
ESR's goodbye note
Why is what this pompous, self important windbag says still considered news in the year 2007, anyway? ;-)
That may be mostly true, but I think he has some good points anyway. His frustration with Red Hat/Fedora almost exactly mirrors my exerience with Red Hat five years ago.
I actually do agree with him upon a few points, myself, in general.ESR's goodbye note
We do need to be going after the iPod generation. ESR's goodbye note
ESR's goodbye note
What exactly is meant by iPod generation?
I think it means people who are perceived by some as having technical skills because they know how to navigate the menu system on an mp3 player.ESR's goodbye note
>"iPod generation" is bunch of people who sold their freedom cheap. Why the hell free software guys should think about them at all - is beyond me. If they sold their freedom for cheap once - why do you think they'll fight for it the next time ?ESR's goodbye note
ESR's goodbye note
From your above post:ESR's goodbye note
Almost the same thing could be said about the Debian project... it has had a lot of infighting... and various political battles that those that don't care about the principles of Free Software don't care much about.ESR's goodbye note
I'm curious in what way you feel the Ubuntu project leeches off ofESR's goodbye note
Debian? I thought they just took a Debian snapshot, tweaked it
to their preference, and released it (similar to what all distros
do with their component packages)?
Check Debian mailings lists. There have been extensive threads about this ESR's goodbye note
issue last year, so you'll be able to satisfy your curiosity with hours
and hours of reading straight from the horse's mouth. This discussion is
really not a good place to start another thread on the topic.
Different words
I'm curious in what way you feel the Ubuntu project leeches off of Debian?
More material for Everybody Loves Eric Raymond.
Look on the bright side ...
I have worked with both formats, and IMHO, DEB is a vastly superior to RPM as a packaging format. DEB is easier to use, better documented, more modular and extensible than RPM, and uses standard tools (/usr/bin/make and shell scripts) instead of a custom tool (/usr/bin/rpm). There is no limit to what you can do with a combination of a Makefile and shell scripts. DEB compared with RPM
It's easy to construct a .rpm archive. Make a .deb archive, and then convert it with alien.DEB compared with RPM
The benefits you're describing aren't a result of any superiority to the 'deb' package format, but rather Debian's strict packaging policies.DEB compared with RPM
"pizza" wrote:
DEB compared with RPM
rick@linuxmafia.com
That page is at http://kitenet.net/~joey/pkg-comp/DEB compared with RPM
I should have said 'package build system' instead of 'package format' in my earlier comment, because the two formats *are* similar at the low level of detail that Joey Hess is talking about. They both contain a collection of files that can be installed and uninstalled, and contain scripts that run during the install and uninstall process. DEB compared with RPM
> The point I was trying to make is that the mechanism for defining and creating a DEB package is superior to the mechanism for defining and creating an RPM package. This is part of the reason why Debian packages are 'better' than RPM packages; the power and flexibility of the build system allows you to design better packages with less effort, which makes the end user's life (and now ESR's life, apparently) easier.DEB compared with RPM
Joey Hess
Having a file dependency on /usr/bin/make when you're going to rely on GNU extensions to Make (and there are several), is a bad idea.how file dependencies can get you in trouble
That's why you can specify explicit packages, if required.how file dependencies can get you in trouble
Searching the package namespace for a dependency is much more efficient than searching through the file list of every package. More importantly, as mentioned by branden, it allows automated dependency resolution to install the right package.File dependencies
There are subtle differences File dependencies
between forex RedHat and SuSE
as to how packages are named
and partitioned.
The packaging policies have nothing to do with it. The mechanism to create a DEB package is more powerful, understandable, and flexible than the mechanism to create an RPM package.RPM vs DEB on technical merits alone.
Your original example for deb:RPM vs DEB on technical merits alone.
For example, if the package needs to install an entry in the system
crontab, you add a line to the Makefile that calls the dh_crontab script,
which merges the contents of debian/cron.d file into the system cron.d
directory.
Your example for rpm:
Add a line to the %postinstall section that has a bunch of
system-specific macros such as:
cp %{_sharedir}/%{pkgname}/cron.entry %{_sysconfdir}/cron.d/cron.daily/%{pkgname}
The thing I find most annoying about building RPMs is that I can't just build them from source in a straightforward manner. Not with "rpmbuild" as an unprivileged user. I have to tar up the tree, compress it, and install it in /usr/src/redhat/SOURCES, and the last step requires root privileges.annoyances of building an RPM
One line in .rpmrc suffices to set up a different build area.
You don't need to be root.
"I don't know how, so it can't be done."
JoeBuck, thanks, even if your subject line is a pretty flagrant distortion of my message. I did say, "if there is a way, my [...] co-workers have not shared it with me.""I don't know how, so it can't be done."
http://myy.helia.fi/~karte/linux/doc/rpm-build-as-user.html covers the basic options you need to do so. annoyances of building an RPM
RPM builds everything from scratch so that you never end up in the situation where the .src.rpm cannot rebuild the .rpm.annoyances of building an RPM
annoyances of building an RPM
Perhaps I should have said that you can't do it as "Just a quick hack to fix the build, I don't have time to do it right."annoyances of building an RPM
as I understand it, the .deb dependancy syntax is more flexible than the .rpm syntaxDEB compared with RPM
Ok, so I did an ldd of rpm, dpkg and apt-get. Yes, rpm has a lot more dependenies... and while dpkg isn't totally static, it is pretty darn close. apt-get, on the other hand, is dependent on quite a few libraries as well... but yeah... a lot less than rpm.rpm vs dpkg - library dependency comparison
There did used to be a static rpm.rpm vs dpkg - library dependency comparison
Despite the speed penalty, dpkg certainly gains some advantages from using text-based rpm vs dpkg - library dependency comparison
data files as opposed to rpm's Berkeley DB back-end. Fewe library dependencies is just
one of them.
At least we'll be rid of ESR's usual cycle on the Fedora devel list, which would go something like this:Finally!
- be told (by many) that things haven't been this way in Fedora for a few releases now (essentially to RTFM and to, of all things, learn how to ask questions :-)
Oh, and if you read the thread carefully, you find out why Mr. Big Hacker was in trouble. He didn't back his system up before doing the upgrade:Finally!
Many Debian-unstable users have had similar adventures: apt-get warns you it's going to delete a whole bunch of stuff, you say "yes", and your system doesn't work right because apt-get deleted a whole bunch of stuff.
Finally!
Fedora users have to back up their system before upgrading? Wow, that's some impressively bad QA. I thought Gentoo QA wasn't great, but I have never ever had a Gentoo upgrade wedge my system into a state where the package manager failed to work.Finally!
> Fedora users have to back up their system before upgrading?Finally!
Finally!
Fedora users have to back up their system before upgrading?
I don't think it's a requirement so much as it is common sense. Not that I use Fedora or Debian (or whatever) but it's just common sense to make sure you have a backup before you do something "potentially unsafe."
> before you do something "potentially unsafe."Finally!
While he certainly did some unsafe things, I do not believe upgrading should be considered potentionally unsafe. At least at the level of a personal system.Finally!
Well, these "some unsafe things" turned out to be rather important libraries. So, the system was hosed. If he used the rescue CD, he could have gotten all those back in a few minutes.Finally!
Yes I acknowledged that.Finally!
Isn't it a bit odd even for him to announce to the world as a press release to all major Linux news sites that he changes the distribution on his machine? Not even the real hackers, who didn't have to hijack a hacker's dictionary just to label themselves hackers, does that.
ESR's goodbye note
That was the part I admired. It wouldn't be on here if he didn't CC lwn. It's a bummer Alan's a-bomb response wasn't CCed to everybody too.
ESR's goodbye note
FWIW, we read the Fedora lists, like we read those of a number of other distributions. We would have seen Eric's note anyway.
ESR's goodbye note
The Art of Unix Programming (2003) is actually quite good and well worth reading.ESR's goodbye note
ESR changes distributions, and posts a rant about why.ESR's goodbye note
Yes, both formats have their limits, but it *isn't* the package manager that is really the problem but the repository. The important thing is that the repository must be up-to-date and self-consistent. If it is, then you'll be happy with either rpm+urpmi/yum or dpkg+apt-get. If the repository isn't in a self-consistent state, then all sorts of *really* bad things happen.RPM vs Deb
look that up in slashdot archives for a good laughESR: Surprised By Wealth
ESR seems to be very unprofessional and childish. Examples:Unprofessional and Childish
* Made up that stupid story about how Bill Gates insulted him at a conference once, and told it to lots of reporters.Unprofessional and Childish
Actually, I don't think his travel rules are obnoxious: he makes veryTravel rules
explicit what folks need to do who want him to come speak, and even says
why. Anybody who doesn't want to meet his conditions should be grateful
for the advance notice, and move on.
who has learned *never* to let anyone else make travel arrangements
for me, I can sympathise (from the opposite end of the spectrum).
this as a matter of principle, up front. While I don't share the
principle, I can understand the frustration. I *have* been in the
position of waiting for months to get reimbursed for expenses from
conference organizers, while having already had to pay the credit
card bills: even one conference like that is enough to make me
wary.
ensure that the folks who *do* book his time are going to value it (people
tend not to do that for things which are "free").
Travel rules
> He claims this as a matter of principle, up front. While I don't share the principle, I can understand the frustration. I *have* been in the position of waiting for months to get reimbursed for expenses from conference organizers, while having already had to pay the credit card bills: even one conference like that is enough to make me wary.Travel rules
Please disregard my comment. I think I misunderstood what you were trying to say.Travel rules
Actually, he is not clear with his rules at all. I once worked on a conference that invited him to speak (along with many others). Shortly before the conference started, he sent me an angry flame complaining about the fact that we had not set up the trip to his exacting specifications. He pointed to that same damn travel requirements document.Travel rules
Too bad that a one-time-visionary almost became something like troll these days. I still remember his high time with 'The Cathedral and the Bazaar'...etc...ESR's goodbye note
ESR's complaints about Fedora are a bit vague. Allow me to clarify them
here.
Translations
Translation: They refused to distribute non-free codecs.
Translation: Upgrade didn't work for me today. Then when I tried to
force
it, it broke.
Translation: QA is a pain. They rejected my package.
Translation: Upgrade didn't work for me today. Then when I tried to
force
it, it broke.
Translation: They refused to distribute non-free codecs.
Translation: They refused to distribute non-free codecs.