Re: pros/cons of installing from source
On Fri, May 04, 2007 at 10:34:27AM -0600, Javier Vasquez wrote:
> On 5/3/07, Greg Folkert <greg@gregfolkert.net> wrote:
> >On Thu, 2007-05-03 at 22:38 -0600, Javier Vasquez wrote:
> >> On 5/3/07, Greg Folkert <greg@gregfolkert.net> wrote:
> >> > ...
> >> > > ...
> >>
> >> Nope, aptitude offers you the dependencies the distro developer
> >> specifies (not just the application developer), some of them are
> >> recommendations, some of them are strictly required. When you are to
> >> compile the application yourself, you can find that even things
> >> strictly required by a binary distro are really not. The reason is
> >> that the distro developer compiled using a particular library for
> >> example, when he/she could have used another or none. So on binary
> >> distros one has 2 levels of non optional dependencies I believe, the
> >> ones set by the original package developer, and the ones set by the
> >> distro developer for the package. This is not true on sourceMage, not
> >> sure on gentoo (it looks like people immediately thinks of gentoo when
> >> talking about source based distros) since I don't know about it, and
> >> it's just because the only really required dependencies on sourceMage
> >> by policy are the ones set by the original package developer.
> >>
> >> Whether this makes a difference or not, it depends on the system one
> >> wants to get.
> >
> >I specifically picked "gd" for that very reason. It supports eleventy
> >options. The reason I picked it, is because the linked set of libraries
> >for Debian pulls in some xlibs on even cursor based systems.
> >
> >Basically the changelog said something like:
> >
> > "the linking of the code against xlibs, only slightly increases
> > the pull in of files amounting to 72KiB, these days this small
> > amount of disk space does not matter. The performance is not
> > affected in any way, but allows for 98% coverage and reduces
> > package count by 12 flavors. If you must have no xlibs, compile
> > it yourself without it."
> >
> >Which, to be honest, is the exact same reason people "restore or rebuild
> >classic cars" or heavily customize the "ricers" they own, or build thier
> >own house or hand craft the Linux Distro of their choice.
> >
> >> I might be wrong though about how debian package developers compile
> >> things though, I'm not one, and it might be that there's a policy to
> >> keep as required dependencies only the ones set by upstream, but I'm
> >> not aware of it.
> >
> >There is the Debian Developers Guide and the Debian Free software Guide.
> >These BOTH have an effect on the Original Source code. BTW, you do know
> >that *EXCEPT* for non-free pieces (like non-source firmware and binary
> >blobs) that Debian include *.orig.tar.gz for everything? They also have
> >a *.diff.tar.gz... so following your comment about "keeping upstream
> >untouched as much as possible" is not-genuine. Debian does this, but at
> >the same time folowing the DFSG.
> >
> >> As a side note, something I liked from sourceMage was its policy of
> >> keeping upstream code untouched as much as possible. I don't know of
> >> any binary distro trying to keep up with that. However this is beyond
> >> the discussion since there's a lot to talk about that, just something
> >> to mention, :).
> >
> >I mentioned Debian Policy (Set forth by the Debian Free Software Guide)
> >as being the BEST reason to run Debian Linux... or Debian FreeBSD or
> >Debian period.
> >
> >> For anything else I agree. Just wanted to clarify a bit further about
> >> the dependencies comment. For not compiling the kernel as a
> >> suggestion, well, again it depends (I don't totally agree). For a
> >> regular user with 40GB of HD or more, there's no problem on having a
> >> blotted set of modules he/she will never use. If you have limited HD,
> >> you'd like to compile only what you need, and not everything so far
> >> supported by the kernel (besides you get more tunned configuration at
> >> the same time for free if you want, I provided the pentium M example,
> >> but I bet there are more, like the kind of pre-emption, the frequency,
> >> etc, not that one gets better performance, but that one gets the right
> >> tunned configuration for the system, and not just a blotted generic
> >> one). Same thing applies to other packages. One might want to remove
> >> any gnome/QT dependency as much as possible, one might not support
> >> some graphics libraries although required for the general purpose,
> >> etc.
> >
> >Good enough, I could pick, but won't. :-P
> >
> >> ...
> >
> >I am fully up on Gentoo. I like its handling, its tools for helping in
> >dealing with packaging and other features... specifically not using
> >upstart (at the moment) and other pieces that traditional UNIX systems
> >have more in common with it. Gentoo is very friendly, it is just picky
> >about its friends.
> >
> >> Please, if I'm completely wrong about my comments on dependencies, let
> >> me know. Maybe there's a debian policiy talking about this (is there
> >> a pointer?) that I'm not aware of, and I was just talking non sense,
> >> :).
> >
> >The Debian Social Contract and the DFSG is located:
> >http://www.debian.org/social_contract
> >
> >The Developer's Guide is located:
> >http://www.debian.org/devel/
> >
> >Specifically though if you want to really read on policy:
> >http://www.debian.org/doc/debian-policy/
> >
> >It ain;t short, but it will help you understand things like we have been
> >discussing.
> >--
> >greg, greg@gregfolkert.net
>
> 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.
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: