Re: debian

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).

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.

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.)

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.

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
.

Relevant Pages

  • 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)
  • embedded linux distributions, a few thoughts
    ... open source distribution that I can customize and recompile from ... packages which are tested together, ... care for .debs to be involved either, if not as packages for the host ... out a quick x86 system" so that it would be easy to start trying them out. ...
    (comp.os.linux.embedded)