Re: What do you wish for in an package manager?
Hamish Moffatt [EMAIL PROTECTED] writes: On Wed, Dec 27, 2000 at 01:03:03AM +, 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 - [EMAIL PROTECTED] - 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''
Re: What do you wish for in an package manager?
Craig Sanders [EMAIL PROTECTED] writes: On Sun, Dec 24, 2000 at 08:41:43PM +, Mark Seaborn wrote: I want a system where I can install multiple versions of a library (or any package really) and say which version I want each program on the system to use, possibly on a per-user basis. The present system is a disaster waiting to happen: If I install a package from unstable, it often wants to replace my version of libc from stable with one from unstable. If this new libc is broken it could bring down the whole system, when what I really want to happen is for the new package to use the unstable libc and everything else carry on using the stable libc. this is the risk you take when you use unstable. if that risk is too great for you, then stick to the stable release. 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 stable, and another user wants to live on the bleeding edge, why should they have to move to different computers? Sure, you could set up a chroot environment for one of the users, but this effectively is the same as using separate machines, and removes many of the advantages of sharing a machine (eg. communication between the two users, and saving disc space by sharing files). it's a small - tiny, even - risk, but it's there. deal with it. the amount of effort and bloat required to implement this idea for the handful of people who would find any use at all for it just isn't worth it. it's a gross violation of the KISS principle and would greatly increase the complexity of systems administration. I strongly disagree. I think it's a matter of finding the right abstractions to make the problem appear simple. when i upgrade a package, i want it to replace the previous version - i don't want to keep the last n versions around just on the off-chance i might have some use for them (e.g. the last 10 versions of libc6 or the last 10 versions of xbooks would waste an enormous amount of disk space). That's fine; an advanced package manager would let you express this preference, and would let more cautious people express their preferences (as well as allowing different preferences for critical packages like libc6 and non-critical packages like xbooks). if i really need more than one version of a library installed, i can compile it in /usr/local and set LD_PRELOAD appropriately. For LD_PRELOAD to work I have to somehow get it into the environments of every program that will start programs that I want to use the new library version. This is particularly difficult for running programs (eg. the GNOME panel). Also LD_PRELOAD only works for C libraries. A better solution might be what Plan 9 does: Each process can have a different view of the filesystem. So you can map different libraries into the filesystem of each process if you want, but leave the rest unchanged. This ought to be doable on the Hurd. -- Mark Seaborn - [EMAIL PROTECTED] - http://members.xoom.com/mseaborn/ - ``I owe a lot to my parents, especially my mother and my father'' -- Greg Norman
Re: What do you wish for in an package manager?
Dwayne C . Litzenberger [EMAIL PROTECTED] writes: So my question is: What do you wish for in a package manager? I want a system where I can install multiple versions of a library (or any package really) and say which version I want each program on the system to use, possibly on a per-user basis. The present system is a disaster waiting to happen: If I install a package from unstable, it often wants to replace my version of libc from stable with one from unstable. If this new libc is broken it could bring down the whole system, when what I really want to happen is for the new package to use the unstable libc and everything else carry on using the stable libc. I want the package system to behave more like a module system for a programming language, particularly a parametric module system such as PLT units. I've put a few e-mails on this topic at http://members.xoom.com/mseaborn/comp/units/, if you want to have a look. -- Mark Seaborn - [EMAIL PROTECTED] - http://members.xoom.com/mseaborn/ - ``Jersey's Crime Prevention Team are out and about, so have you locked up your property?'' -- Roger Bara
