On Thu, Nov 08, 2007 at 12:18:15PM -0800, Bryan J. Smith wrote: > 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).
Source RPMs are a pain to deal with. Debian's sources are a lot more sane, and debian's tools make life a lot simpler. > "Do what's right" is relative. > > Not for leading-edge development where you want to build everything > against various libraries. The libraries should be packaged too. > 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. Debian actually managed to evolve rather quickly. They are slow to release because testing that many architectures and that much software properly takes time. Other distributions have a much lower bar for "good enough" than debian. > 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. I wouldn't want to gut the whole system, I only replace the bits that need to be replaced to get what I want. > > 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. Well debian does modularize some things (like php for example) which works rather well. > 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. I still think you are better off with debian's system. I find most debian source packages very easy to work with an update. And debian's debhelper toosl automate a lot of the dependancy tracking (like figuring out which libraries what I just built actually uses and which packages those libraries came from). I have found it much more efficient to use the package system, even when updating stuff myself to keep things consistent and working. You have to figure out what library versions you need either way, and making the package is a rather small part of the work. I moved from SLS to slackware because SLS wasn't going anywhere. I moved from Slackware to RedHat because RPM package management was clearly better than Slackware's (and SLS's) system. I moved from RedHat to Debian because Debian's system was clearly better than RedHat's and to get away from RedHat's many annoying bugs in their releases. I most certainly won't move to Gentoo ever because ports are clearly not better than what Debian does, and in fact is more on the list (along with for example the Pentium 4) of things that are clearly fundamentally wrong by design. You can get good software from BSD, but you sure can't learn how to make a good user space or package system. > > Well many developers do like breaking their machines, so I guess > > having them run gentoo would be no different. > > Exactomundo. I consider that to be a trait of bad developers. > > 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. Well if you don't actually want anyone to ever use your code then I suppose not. I have never worked in a place where that was true. > 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. The QA yes, but that doesn't mean you have to throw out everything else. -- Len Sorensen _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
