Lennart Sorensen <[EMAIL PROTECTED]> wrote: > It is just as easy to update a debian package.
No, sorry, source DPKG and RPM are not the same, and I say this as someone who has maintained both for a long, long time (and still do). > Packages never get in the way. They do what is right. "Do what's right" is relative. Not for leading-edge development where you want to build everything against various libraries. Debian evolves slow because they create so many cross-links between various packages. Red Hat solves this by just standardizing on one library, which is too much the other way. At some point the dependency resolution is the instigator, not the resolver. If I'm only building a few packages, that's one thing. I want to leverage all of the integration and regression testing done by Debian, Red Hat, etc... But when I start changing entire trees in the distro, I'm undoing all of the integration and regression testing anyway. So at that point, I've made integration and regression testing my own responsibility. So I might as well use a distro that focuses on porting, not packaging. That's where Gentoo is virtually the only distro -- because they focus on a porting approach, not a packaging one. Understand I'm not some Gentoo car-mod like moron. 90% of Gentoo users give it a bad name. I make over 90% of my money on RHEL. I love the Fedora-RHEL approach to community-enterprise development. But for leading edge development, or entire software stacks where you're gutting what the vendor has done, it's better to stick with a porting approach, not a packaging one. > If you work with it and actually do things right it will > avoid lots of problems. You're preaching to the choir. I'm not a Gentoo puke who thinks source is everything, quite the opposite. So don't treat me like one I'm just saying when you start gutting major portions of the distro, using packages is futile -- it not only gets in the way, but you've utterly destroyed any integration/regression testing done. > If you just barge ahead and try to ignore dependancies, > then you get what you deserve. Agreed! But when dependencies are due to a packager's rationale and focus that _conflicts_ with your own, then it is _not_. > If the package doesn't do what is right then the person > that made it made a mistake. *NO*! Packagers cannot build for every environment. Debian tries to and is heavily burdened. Red Hat standardizes and is too rigid at times. Rigid is great in RHEL for its 7+ years of ABI/API analness, or even Fedora community releases when it's clear what the future holds. But before the future is defined, a porting build is the only way to play with things without having to repackage everything when you change one thing. > If someone screws up the rules in ports, then it doesn't work > there either. With ports, *YOU* the end-user builder responsible. *YOU* have to do your own integration/regression testing. But guess what? *YOU* do that anyway when you go against what Debian or, even more often, Red Hat decided was "the standard" or "the options" in the distro. You undo all of that integration/regression testing. That's the delima of whether to use ports or packages. When you're undoing all of the benefits of a packaged distro, it's just better to go with a ports-based stack. > Well many developers do like breaking their machines, so I guess > having them run gentoo would be no different. Exactomundo. > Of course at some point you have to make sure the code being > developed actually works on the target system. That's not a concern with leading edge development. Using the Red Hat model, that only starts when Fedora starts adopting things, of which are what the next version of RHEL will have. I'm not talking about sustainment development or even mid-development, but early development. I'm also talking about when someone utterly guts the Apache modules from a distro and replaces them. At some point, the entire QA on that stack has been voided anyway. -- Bryan J. Smith Professional, Technical Annoyance [EMAIL PROTECTED] http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
