Ports management tools in the base (Was: Re: cvs commit: www/en/projects/ideas ideas.xml)

[Andrew Pantyukhin]

On 3/21/07, Pav Lucistnik <pav at freebsd.org> wrote:
> Andrew Pantyukhin píše v st 21. 03. 2007 v 11:31 +0300:
> > On 3/21/07, Alexander Leidinger <Alexander at leidinger.net> wrote:
> > > When you need a program which needs a newer lib than installed on a
> > > production system, but you don't get a maintenance window to update
> > > all other programs which use this lib, then not having the old lib
> > > will hurt.
> > >
> > > When the reason for the library version bump also requires to change
> > > some parts in the source of the programs which make use of the lib,
> > > you have to update all programs at once. If some programs have bugs in
> > > more recent versions which you can't accept in production and when you
> > > need to install a program which needs the new lib version, you are
> > > busted when you don't have the old lib around.
> >
> > But don't you smell an architectural flaw here (of the
> > ports system) and don't you feel that working around it
> > in a tool in the base system might only mess things up
> > even more?..
>
> No I don't see a systematic flaw here. Or you suggest we reset all
> shmajors everywhere to zero?

I would suggest that multiple versions of any port
should be allowed to be installed simultaneously -
and without the burden of introducing versioned
ports.

I do not volunteer just yet to propose an outline
of a solution to make that possible, but workarounds
have a tendency to be tolerated in the long run once
introduced into the base system. objformat tool is a
nice example of such a workaround.