pjones at redhat.com
Mon Jun 6 21:34:16 UTC 2005
On Thu, 2005-06-02 at 08:46 -0400, Paul A. Houle wrote:
> > MacOS X packaging works reliably for end users, 100% of the time, and
> > from that perspective it doesn't matter how many features it has or
> > doesn't have, it's better than yum/rpm/any Linux packaging system.
> This is something I've thought about: how much would the shell slow down
> if we had a very long $PATH, so that we can give applications independent
> bin directories?
The bigger issue is likely to be limited size in which to store the
data. ISTR you get a page or something like that to put environmental
data in during exec(). Kernel guys correct me, I'm sure it's bigger
than that but totally fuzzy on the details.
Anyway, you might do better by making some way to marking "this file
here needs to be made into program named 'foo' in the (user/admin)
default path" in the package, or in a file at a well known location.
Sort of like how pkg-config tells you how to link against a library.
Then you can separate out the responsibility of how to make it
executable, and have something that knows about the distro's policy do
the work of making it available (whether by symlink, copy, hardlink,
etc). This could be during package install, or at boot time, or in an
initscript when starting some particular service.
> A downside to giving each app a directory is that it's harder to use
> partitions to isolate different kind of things, an art that I've been
> learning over time (and particular inspired by the Solaris shop I work
> with that uses something much like LVM, allocate a minimal amount of
> space for each partition, leave a large free pool, and grow the
> partitions online over tine)
You could, uh, use lvm for that...
More information about the devel