On Fri, 2007-05-04 at 13:22 -0600, Javier Vasquez wrote: > On 5/4/07, Andrew Sackville-West <andrew@farwestbilliards.com> wrote: > > On Fri, May 04, 2007 at 12:42:40PM -0600, Paul E Condon wrote: > > > On Fri, May 04, 2007 at 10:34:27AM -0600, Javier Vasquez wrote: > > > > [heavy snippage dude] > > > > > > > > You mentioned debian commitment to FSF and its social contract, > as > > > > very good reasons by themselves to run debian. I totally agree. > > > > However debian is not the only distro with such commitment. > Actually > > > > sourceMage picked debian social contract and modified it a > bit... > > > snip... > > > > > > I understand Greg's comments to be about Debian's commitment to > > > enforcing a packaging policy, i.e. a policy on where and how > things > > > are installed. To me is quite a different thing than a social > > > policy. In Debian, if the install scripts of a package to not put > > > things where the policy says they should be _that_ is a bug in the > > > package. It may also be considered a bug in some other distro.s. > I've > > > not kept track of this sort of policy issue in any other distro. > since > > > I discovered Debian. > > > > > > The Social Policy is also good. But I think it is easy to feel > good > > > about a Social Policy, and it is hard work to implement a > packaging > > > policy. > > > > > > I think that the packaging policy is what really sets debian > > apart. THat's why everything "just works"... because dev's can count > > on things being a certain way and if its not, they can count on it > > being fixed. > > > > A > > Hmm, OK, we're changing the original topic now, but it's OK. I didn't > want to comment more, but I think there's a confusion here. On a > binary distribution you required a packaging policy, since you have > different package developers, and in order to keep a coherent > functional and robust system (dependencies, etc), you need to enforce > a packaging policy. Debian packaging policy has demonstrated to me by > far to be the best (personal opinion here), and not now, almost from > the very beginning. Yes, only Debian does the Policy and enforcing of it. It is my whole point about policy. > However on a source based distribution, there's no different package > developers, the admin of the system is the developer at the same time, > and he/she is the one deciding what to compile against (libraries, > dependencies whether strict or optional, etc). Okay then, so how do you work through all the "problems"? Like a fail to compile due to a slight change in libfoozle that is incompatible with program blarfengangle's method of factoring? > Furthermore, sourceMage, and probably other source based distros also > have their own packaging policies. In sourceMage for example the > "spells", include a section for dependencies, just like in debian, and > the required dependencies by upstream are included there. Beyond that > there are 2 release branches, one stable, and the other testing, plus > a development environment. Nothing goes to "stable" if the testing > community is not satisfied about it. Again, just because something is "compiled against" something else does not needlessly mean that it is slower or faster or even better or worse. I'd like to know how you delve deep into the deps on things for HUGE packages such as X.org or OpenOffice or GNOME or KDE. Seem there has to be a packaging policy being foisted on you by someone. Which if you REALLY want to build you own Linux, you need to boot a LiveCD, Download source for the "base" libraries, compile them for a chroot. Install them in the chroot. Then compile the compilers and install them in the chroot. Then configure and compile your compilation tools (like autoconf, automake, m4, awk... etc) and install them. Finally chroot into the adhoc area. Then download and build the Kernel and other critical packages. Then a bootloader (grub/lilo/elilo/whetever) compile it and install it, then write the MBR for it. Once that is done, setup the booting stanzas and re-run the "updating" or what have you script to get it possible to boot from the disk. Once booted, you get to "rebuild" everything you just built, so you get "native" builds (and don't forget to heavily optimize) and not cross/non-native builds. From that point forward, you get to download HUGE tarballs and then configure them... grab pieces you forgot/missed to for things you want enabled, like DNS resolution is a good thing, recompile everything again to use DNS resolving libraries... Then restart the X compilation, finding yet another core thing usually caught... compression... egads yet another "make world" and the list goes on and on and on. > I think there's no way to compare packaging policy between a binary > distro and a source based one. Yes there is. Gentoo has one, SourceMage has one. Unless you force things into NON default locations, you are following packaging policy. Sort of like ports on *BSD. > The philosophy is completely different. It actually is not very different at all. sourceMage requires things in particular places and to use specific calls. Just like Debian does, though sourceMage is much more "lax". > On a binary distro the policy is enforced to the distro package > developers, while on a source based one the developer is oneself, and > even considering that, there are policies enforced by the original > application developer which are enforced... Remember that it's not > entirely correct to compare oranges against apples. Ok, so what makes you think that putting anything and everything differently is going to make you source based distro any better or more supportable? Support of users is why Debian Packaging Policy is KING. SourceMage may allow you more flexibility, but think about how difficult it will be for an upstream developer to trouble shoot or debug and obscure problem triggered by your installation... only because you don't have the "very seldom left out lib-flitzer option" normally included by default in "glibc v2.0 and later" but you don't what that... it another 25KiB and I don't want no stinking developer telling *ME* what to do. I ask this, because, the things like preempt in the Linux kernel has a lot of troubles. Many times the real problem comes down to a rare and exceptionally obscure machine configuration on a "source" based distribution. Ok, I'll stop ranting about the evils of source based distros. The one point you make time and time again, is "I get what I want, when I want it and how I want it" This is very true in source based distros. But is the actual work involved becoming a 1337 h4ck3r, really worth the time and energy? That is unless you are going to develop for a Binary distribution. /me shuts up now. -- greg, greg@gregfolkert.net Novell's Directory Services is a competitive product to Microsoft's Active Directory in much the same way that the Saturn V is a competitive product to those dinky little model rockets that kids light off down at the playfield. -- Thane Walkup
Attachment:
signature.asc
Description: This is a digitally signed message part