Re: debian

On 2006-04-24, Moe Trin <ibuprofin@xxxxxxxxxxxxxxxxxxxxxx> wrote:
On Sun, 23 Apr 2006, in the Usenet newsgroup alt.linux, in article
<124lqhfbtpj9i3f@xxxxxxxxxxxxxxxxxx>, Jimchip wrote:

In Debian it goes in /usr/local/ and the package manager is 'trained' to
ignore that directory.

Linux Standard Base Core Standard http://www.linuxbase.org/spec/
Filesystem Hierarchy Standard http://www.pathname.com/fhs/

and for that matter, it's also discussed in the LDP Guide titled
"Linux-Filesystem-Hierarchy" which is sort of a lay-man's translation of the
two documents above.

Briefly, a distribution should ALWAYS leave /usr/local/* alone. That tree
is for use of the system administrator. /opt is reserved for the
installation of add-on application software packages. But in both cases,
the system administrator may very much wish to use the package manager to
do the installs. Additionally, the author of an after-market package may
fail to follow the FHS requirements about staying the heck OUT of the
system directories, like /bin/ or /sbin/ et.al. (a very _common_ mistake).

That's the problem..."fail to follow the FHS...". My point was that Debian
is strict about it.


One does get into a spiral that can finally negate the benefits of
'standards' with a particular distribution.

Yes, and that's why newbies (and less experienced admins) should avoid
installing third party packages unless those packages were specifically
built for the specific distribution and release that they have. You may
be able to get a Mandr* package to install into Red Hat/Fedora, but that
is often asking for problems. With rpm, it's much safer to get the source
rpm, and build that into a binary (there will be a lot less complications)
but it's not foolproof either.

It's a little the same with Debian in the sense that a source build will
catch any dependencies...libraries don't always match. Debian recommends
starting with source in /usr/local/src/whatever_program and then
/usr/local/bin/whatever_program, /usr/local/lib/, /usr/local/etc/ for the
typical files. Not really bad but, in my case anyway, I really need a good
reason to bother.

Dependencies. Your 'alien' idea is a good 'ideal' choice but the
interdependencies make it too difficult to accomplish automatically with a
package manager (except in a very limited way.

Timeframe Debian Red Hat
mid 1996 buzz 474 packages picasso 387 packages
current sarge 8560 package Fedora Core 5 2207 package

(That number for sarge seems awfully high, while the number for RH3.0.3
seems somewhat low, but illustrates the problem.)

15,180 total packages is what the Debian FAQ claims (June, 2005) are in
"the distribution".

When 'alien' came out in the mid-1990s, there weren't that many things to
worry about. For what it's worth, alien was supplied as part of several
rpm based distributions as well as Debian.

It's just not automatic but where there's a will... :)

I don't want to work out source packages either.

Looking at the notes on this workstation, there are about 400 distributor
packages installed, and about 20 third party packages. There are probably
a hundred additional packages installed from tarballs, that do things that
the distribution never saw a need for. By the same token, that 400 packages
count is just under a quarter of the packages that were supplied by the
distributor. The bottom line is that no distributor can please all of the
users.

Old guy

Don't I know it.

Still, it's not too bad if one knows what (or where) their particular distro
is going to be nice about 'foreign' packages. A lot of times,
compiling/installing into a home subdirectory followed by a /usr/bin/symlink
can be a good compromise. Keep a few notes and just rebuild (ugh, in your
case maybe 120) symlinks.

--
It might depend on how much a person upgrades anyway.
.

Relevant Pages

  • Re: debian
    ... Linux Standard Base Core Standard http://www.linuxbase.org/spec/ ... installation of add-on application software packages. ... built for the specific distribution and release that they have. ...
    (alt.linux)
  • Re: Fedora Extras is extra
    ... BTW Some Red Hat packages used to have similar things ... > external contraints allow you to bend to work inside what fedora ... > but not their own infrastructure for distribution. ... Fedora Extras will have the same policy. ...
    (Fedora)
  • Re: distribution points
    ... I'm wondering why you choose at logon for doing the patch installation? ... >>> Office to small bespoke packages for just a few clients. ... distribution points are meant to get SMS packages close to ...
    (microsoft.public.sms.misc)
  • Re: determining the smallest Linux installation to run a particular app
    ... >> Because my Linux app needs to be distributed with the OS, ... >> to minimize the overall size of the distribution, ... >> the smallest set of packages that are required to run my app. ... if your installation is kickstart based or your ...
    (comp.os.linux.setup)
  • Re: Secrecy and user trust
    ... Were packages signed by the replacement key distributed? ... trusted "new" public key, it can be used to check the signing on any ... The current distribution has the ability to do this, ... I can't say if any updates past the install ...
    (Fedora)