Re: What do you wish for in an package manager?
Hamish Moffatt <hamish@debian.org> writes:
> On Wed, Dec 27, 2000 at 01:03:03AM +0000, Mark Seaborn wrote:
>
> > Of course. I know this. It is repeated many times on this mailing
> > list. But it does not have to be so. Why should upgrading package X
> > affect unrelated package Y? If one user wants to use packages from
>
> Package X and package Y are not truely unrelated if they share any
> dynamic libraries, though, eg libc.
They are unrelated if they do not need to communicate (as an
example). If they do not need to communicate, they may as well run on
different machines, in which case they can use different versions of
libc. But I want to be able to merge those two machines into one --
this is what a multi-user system is all about -- and have the two
programs continue to use different libcs.
> So do you have any suggestion as to how this could actually be
> implemented? Even if it's actually desirable (which I dispute),
> implementation seems far from trivial.
I just remembered one of my original reasons why this was
desirable. :-) At present I find that the barrier to modifying
programs is too high; it is too much effort to make a few casual
changes to a program. For instance, it has always bugged me that
clicking the right button on the arrows on Gtk's scrollbars doesn't
scroll in the opposite direction. I expect this is easy to change.
One of the problems, after modifying the code, is getting programs to
use it. I could install my modified package over the original, but
when I'm just testing my hack this is far too slow to do for each
little tweak, and it's stupid because my hack could bring down any Gtk
program I start up. The other option is to mess around with PATH,
LD_PRELOAD, etc., and apart from the fact that it is fiddly and
aesthetically displeasing, it is not a generic method and will not
work with Perl code, Scheme code, XPM files, or any other arbitrary
files that packages contain.
I am lazy, and I end up never making these small tweaks because it is
not worth the hassle. And I never get drawn in to making bigger
changes...
As to suggestions for implementation, I have a couple.
As I suggested before, it would be easy if different processes could
have different views on the filesystem. This is feasible on the
Hurd. Linux is not as flexible, unfortunately. I can envisage
modifying libc so that it is possible to redirect files elsewhere on a
per-process basis (ideally this would be done in a general manner so
that a call to open() could be forwarded to a server in another
process, which would then pass back opened fd).
(I'm very interested in user filesystems in general. I played with
perlfs last year, but it was too unreliable, and it broke when I
upgraded perl anyway. Modifying libc now seems the way to go, but I'm
not prepared to hack libc on this level yet.)
Another approach is more on a language level than a system level, and
involves creating a better module system (for C, initially) that can
also double up as a package system -- something based on the `units'
system for Scheme (I've put links to papers describing this at
<http://members.xoom.com/mseaborn/comp/units/>). This is a module
system where modules are first class and parametric (while still
allowing mutual recursion between modules). Extending it to be typed
and to allow the export of macros from modules will make it suitable
as a module system for linking everyday C code.
Making the interfaces between bits of C code more explicit will make
it easier to generate glue code for calling C from other languages.
It will make it easier to handle issues associated with interface
changes, and spot better when code needs recompiling to handle a macro
changing.
I intend to work on this some time, so I intend to show by example
that it's quite useful. :-)
--
Mark Seaborn
- mseaborn@bigfoot.com - http://members.xoom.com/mseaborn/ -
``Water boils at a lower temperature at high altitude, which partly
accounts for the nasty taste of coffee on the summit of Mauna Kea''
Reply to: