l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
April 21: Google Glass
Next Installfest:
TBD
Latest News:
Mar. 18: Google Glass at LUGOD's April meeting
Page last updated:
2005 Apr 09 21:02

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Compile Question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Compile Question



on Fri, Apr 08, 2005 at 06:16:41PM -0700, Rick Moen (rick@linuxmafia.com) wrote:
> Quoting Henry House (hajhouse@houseag.com):
> 
> > I'm glad you were able to make progress.
> > 
> > Tips for future reference:
> > 
> > - "dpkg -l |grep kde" tells you if you have any packages with "kde" in their
> >   names installed
> > - Debian development packages almost always are named lib*dev, so, for
> >   example, you know that you don't have what you need to compile with KDE
> >   if you don't have a package with both kde and dev in its name.
> 
> Good tips.
> 
> I'm sure there are exceptions, but in my experience, and with a few
> exceptions[1], if you find yourself compiling a tarball[2] to install a
> package on Debian, you're almost certainly solving the wrong problem.
> That is, you really, really want to stay within the package regime if
> reasonably possible.

First off:  I agree with this completely.

However, I'd like to hammer down _why_ this is recommended.
Particularly in light of an apparently emergent business model of
providing alternative packaging for various application stacks.

Off the top of my own head, advantages of PMSing (going through your
package management system):

  - PMSing buys you bug updates, security updates, bugtracking, and
    issue resolution through your PMS system.  Not PMSing requires you
    to keep on top of bug updates for all locally maintained packages.

  - PMSing buys you 1000+ other maintainers (the package maintainers for
    your distro) who generally track a given package.  Not PMSing
    requires you update and maintain whatever packages you've installed
    locally, meaning keeping up to date with upstream.

  - PMSing buys you many eyeballs, in the form of other users of the
    distro whose experience is going to closely track your own.  Not
    PMSing means you may have introduced quirks in your configuration,
    build, or deployment which aren't part of the standard experience,
    and for which you've got the joy of discovering on your own.

  - PMSing buys you an existing relationship between your packages'
    maintainers, and the upstream maintainers of those packages.
    Upstream is more likely to listen to Joe Major Distro maintainer,
    and be responsive to emails, than Joe Random User.  Will vary, of
    course.

  - PMSing buys you one-point shopping for updates and upgrades.  Rather
    than finding, tracking, downloading, compiling, fixing, and
    installing a swatch of locally maintained packages, you issue your
    update, (optionally:  download), and install commands.

  - PMSing, on a Policy-based distro, buys you Sane Behavior among
    various installed components.  If packages foo and bar have
    overlapping functionality, PMS either conflicts them (so they can't
    be installed together), isolates the common components (so that this
    can be handled independently of the remainder of the package(s)), or
    handles preferences for which package should take precedence over
    the other (e.g.:  installing multiple X Display Managers ([gkwx]dm)
    but specifying one as the preferred option).

    Not PMSing introduces the possiblity that externally sourced
    packages conflict with other PMS software, or each other.  In ways
    which result in the dreaded Finger Pointing Loop Condition (FPLC).
    You've got a system serving two masters, and that's a tough call.


On the plus side:

  - Not PMSing allows you to track current, experimental, or
    not-yet-packaged software.  A sane Policy-based system will provide
    you with an installation area (e.g.:  /usr/local/, /opt/) under
    which all management is handled locally, rather than by the PMS, and
    for which the PMS is forbidden from making any potentially harmful
    changes.  E.g.:  Debian policy allows for creating certain
    subdirectories under /usr/local, but not for the creation of files,
    or for deleting files or directories.


There are also ways of gaining better management over unpackaged
software, including tools to create packages (e.g.:  alien), tools to
manage installation / removal (GNU stow), and tools to register
capabilities of unpackaged, but installed, software (e.g.:  Debian's
'equivs').


Peace.

-- 
Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    George W. is deceptive to be sure. Dissembling, too. And let's not
    forget deceitful. He is lacking veracity and frankness, and void of
    sooth, though seemingly sincere in his proclivity for pretense. But
    he did not lie.
    http://www.jointhebushwhackers.com/not_a_liar.cfm

Attachment: signature.asc
Description: Digital signature

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech


LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.