The need for multiple versions of an application on one machine doesn't manifest that often. Asking the system to tie itself into knots for this purpose is likely to result in bloat, convolution and less reliability.
Some contexts support and indeed encourage the notion of many versions. For instance, the Ruby Version Manager (RVM) allows different versions of the Ruby interpreter and its attendant libraries to be in use at a given time. It seems to work perfectly well, but one has to wonder if this is really a good thing. Do you really want the mental overload that results from having to deal with multiple versions of a language, library, API, user tool, or whatever? The original poster might want to consider whether this kind of thing is necessary or desirable. It sounds symptomatic of half-baked ideas about what needs to be accomplished and how to accomplish it. Also worth considering is OpenBSD's stance on how to maintain a system. You are encouraged to refresh the system at six month intervals and, in so doing, become familiar with the nature of the software you're running. Chances are, the version they've packaged works well enough, probably better than older incarnations. Incidentally, you can learn what files comprise a package with: pkg_info -L <package-name> You can learn about the package related commands by typing: apropos pkg_ And then reading the listed manpages. As always with OpenBSD, these documents are of high quality. Chuck On Aug 2, 2014, at 4:17 AM, Gustav Fransson Nyvell <gus...@nyvell.se> wrote: > On 08/02/14 13:13, Gustav Fransson Nyvell wrote: >> On 08/02/14 12:54, Marc Espie wrote: >>> On Sat, Aug 02, 2014 at 12:26:06PM +0200, Gustav Fransson Nyvell wrote: >>>> Hi, there, >>>> >>>> I wanted to run something by you, mkay. About package management. I wonder >>>> if this has been shouted at already. I remember from SunOS that packages >>>> are >>>> installed in a different manner than let's say Red Hat and of course >>>> OpenBSD. They install it in the form /pkgs/PROGRAM/VERSION, example >>>> /pkgs/gimp/1.0. GoboLinux does this. I think this has some advantages over >>>> installing /usr/local/bin/gimp1.1 and /usr/local/bin/gimp2.0. What do you >>>> think? What have you said? >>>> >>>> Ready to be shouted at; >>> This puts more strain on the file system actually, which is probably >>> the main reason we don't do it. Also, there is generally a lot of churning >>> to do to make the package self-contained. >>> >>> As far as policy goes, having stuff set up like that looks more flexible, >>> but >>> it is a fallacy. Instead of having the distribution solve issues concerning >>> incompatible versions and updates, the toll falls instead on the individual >>> sysadmin, to make sure things they have work together. It can lead to >>> security nightmares, because it's "so simple" to have the newer version >>> alongside the old version that sticky points of updating take much longer >>> to resolve. >>> >>> It's a bit like having mitigation measures that you can turn on and off... >>> if it's possible to turn these off, there's not enough incentive to actually >>> fix issues. >>> >>> Likewise for packages. By making it somewhat LESS convenient to install >>> several versions of the same piece of software, we make it more important >>> to do timely updates. >>> >>> Also, we don't have the manpower to properly manage lots of distinct >>> versions >>> of the same software. So this kind of setup would be detrimental to >>> actually testing stuff. >> I guess there could be both. But I think that if there's a security issue >> with one version of a software then there quite possibly are multiple ways >> of limiting the impact of that issue. Disallowing multiple versions to force >> people to upgrade is not really a good reason, from how I see it. Old >> software will always have more holes, because they're older and more well >> observed, but they have qualities, too, like speed. GIMP-1.0 is amazing on >> Lenovo X41 from 2005, but probably has bugs. Of course none of these systems >> will stop someone who wants to run version x of a software. Maybe something >> entirely different is needed? Okay, maybe I should complain about the status >> quo... thing is when packages install in /var, /usr, /etc and /opt they're >> so spread out it's hard to know what is what. This might be because I'm new >> but/and scripts can find orphan files in this structures, but you need the >> scripts for that. Having everything in /pkgs/PKG/VER would not cause this >> splatter. P! rograms without dependees (i.e. non-libs, non-utilprograms) could fit in this structure without any extra filesystem magic. Well, the grass is always greener. >> > BTW, you create multiple versions by your mere existence. There are lots of > old versions laying around, but they can't be installed together right now. > > -- > This e-mail is confidential and may not be shared with anyone other than > recipient(s) without written permission from sender.
