Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Don't be misledDon't be misledPosted Sep 18, 2003 5:15 UTC (Thu) by ncm (subscriber, #165)Parent article: Revisiting RPM Package Management It is a fundamental error to equate a ported apt-get with Debian's package management. Most of the value of Debian's packaging isn't in apt-get at all, but lies rather in Debian's packaging policy and its enforced application to the contents of packages. Apt-get just takes advantage of the enforced policy. Without that policy, apt-get is a hollow shell; it can automate downloading, which looks nice, but can't prevent problems of incompletely described package interactions. The reason this matters is that users of apt-get and its offshoots on other distros might come to believe that Debian, raided for its convenient apt toolset, has nothing unique left to offer. On the contrary, for example, Debian's more careful library naming policy eliminates most library version problems. On other distros you must manually override the package manager, which can't track multiple library versions, and in so doing you are likely to break your installation. It is almost never necessary to override the Debian package manager's judgment; in six years I have only done so while purging third-party packages that turned out to be faulty. A Debian system can be fully upgraded by the package manager from one major release to another without a dangerous "reinstall". Most Debian users only ever install once on any given machine, and upgrade incrementally at need, without rebooting. Anyone who wonders where the hundreds of volunteers have applied their efforts, instead of delivering a flashy UI installer, should consider that they have not been idle. Other distros can lift apt-get, but they can never afford to duplicate the deep work on system coherence that has gone into Debian.
(Log in to post comments)
Don't be misled Posted Sep 18, 2003 5:22 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] I've successfully updated Red Hat distribution versions using only apt-get (using several separate steps; I wouldn't dare try just one dist-upgrade on either a Red Hat or a Debian system), and I've also had more problems with doing the same on Debian than Debian advocates claim. The Debian people are more careful and organized, but they do make mistakes.
Don't be misled Posted Sep 18, 2003 6:08 UTC (Thu) by Ross (subscriber, #4065) [Link] I agree. RPM should be compared to DEB, not to apt. Of course RPM alsofails to support all the nice features of DEB and it was introduced long before apt. It may predate RPM, I don't remember.
Don't be misled Posted Sep 18, 2003 10:31 UTC (Thu) by leandro (guest, #1460) [Link] > Of course RPM also fails to support all the nice features of DEB and it was introduced long before apt. It may predate RPM, I don't remember. AFAIR deb was conceived before rpm but saw the light of day after: Red Hat didn't want to collaborate with (and wait for) the right thing, so they got an access of NIHS and went their own way with their own half-baked stuff, thus fragmenting the community. And here they go again with yum over apt. Sad.
Don't be misled Posted Sep 18, 2003 14:46 UTC (Thu) by skvidal (subscriber, #3094) [Link] Hi,I don't work for red hat. I work for duke university. I'm a sysadmin there. I'm the author of yum. I think one of the reasons red hat has put yum in rawhide before apt (and note, it's just BEFORE, it's not INSTEAD) is that yum, is about 7000 lines of code, while apt is 40000+. Also yum is in python which we all know red hat is far more comfortable in. I don't think this has anything to do with denying debian or NIHS b/c they didn't invent yum. Also, if you'd look closely at up2date in rawhide you'll notice that is has support for both yum and apt-rpm repositories. -sv
Don't be misled Posted Sep 18, 2003 15:08 UTC (Thu) by DancingProg (subscriber, #4816) [Link] Thank you for the info and the great tool.
Don't be misled Posted Sep 18, 2003 22:36 UTC (Thu) by hazelsct (subscriber, #3659) [Link] Indeed, thank you for the great tool, the difference in line count is impressive.Debian's decision to use C is a sound one however, because python would bloat the base system significantly. apt-get in stable on i386 is about 153 kB (not kiB); python alone is about 518 kB. So as Debian and derivatives (e.g. Familiar) are installed on embedded systems from iPaqs to routers, the significantly smaller base system -- without sacrificing automatic dependency management -- is an advantage. But perhaps RedHat is not concerned with such markets.
Don't be misled Posted Jan 6, 2004 17:38 UTC (Tue) by leandro (guest, #1460) [Link] > I think one of the reasons red hat has put yum in rawhide before apt (and note, it's just BEFORE, it's not INSTEAD) is that yum, is about 7000 lines of code, while apt is 40000+. This has more to do with their homegrown RPM that they decided to use instead of help finishing dpkg at the time.
Don't be misled Posted Sep 18, 2003 7:01 UTC (Thu) by Frej (subscriber, #4165) [Link] Like the not so clever naming of libXML perl module?'libxml-libxml-perl'
Re: Don't be misled Posted Sep 18, 2003 7:56 UTC (Thu) by tarvin (subscriber, #4412) [Link] I've recently considered switching to Debian, because of the uncertainties surrounding the future of Red Hat's free distribution, and because of the very short support-lives that have been announced for the free versions of Red Hat's distribution.Unfortunately, it seems that digital signing of deb-packages hasn't proceeded significantly. In effect, Debian still doesn't offer pgp-signed packages. Does anyone know if digitally signed deb-packages might be realistic with a forseeable future?
Re: Don't be misled Posted Sep 18, 2003 9:38 UTC (Thu) by rganesan (subscriber, #1182) [Link] Individual Debian packages are not signed but a Debian archive/mirror is quite safe. First, any upload of a package to the primary FTP site is digitally signed (not the package itself, but the package "description"). Next, debian signs a Release file which contains the md5sum of the "Packages" file which contains the list of all packages. Finally, the Packages file contains md5sums of each individual package. Seehttp://www.debian.org/doc/manuals/securing-debian-howto/ch7.en.html#s-deb-pack-sign
Don't be misled Posted Sep 18, 2003 22:23 UTC (Thu) by hazelsct (subscriber, #3659) [Link] Indeed. Debian's network of volunteer package maintainers is the envy of companies like RedHat and Mandrake, which is why they are trying to switch to the Debian model. In the end, though, they're just Debian Wannabees, and their corporate-centric governance model is doomed to fail. Bwa ha ha ha ha!
The Debian "Model" Posted Sep 19, 2003 3:47 UTC (Fri) by lovelace (subscriber, #278) [Link] Mandrake isn't trying to "switch to the Debian model". Mandrake has been put together byvolunteers in the Cooker project for quite a while. While they are putting together a community with the Mandrake Club, packages created there are not included in the base installation.
Debian Packaging Policies Posted Sep 19, 2003 3:38 UTC (Fri) by lovelace (subscriber, #278) [Link] You're right, Debian's packaging policies add a lot to how well it can deal with things likelibrary version conflicts. That's why Mandrake adopted the same policies with version 8.0. I would love to see Red Hat do something like this as it really does simpilify the problem of multiple library packages without doing hacks like saying that this packages that was formally named foo is now foo1.0 and the current package foo is now version 2.0. One other thing of Debian's Mandrake uses is the Debian menu system. This allows the Most of Mandrake these days is put together by volunteers working on the Cooker project. I
|
|||||||||||