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

Andrew Pantyukhin infofarmer at FreeBSD.org
Wed Mar 21 11:29:19 UTC 2007


On 3/21/07, Pav Lucistnik <pav at freebsd.org> wrote:
> Andrew Pantyukhin píše v st 21. 03. 2007 v 13:55 +0300:
> > 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.
>
> How would that work? I'm curious.

Several systems have such a feature. SEPP for one.

> > 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.
>
> Let's say I prefer a working system now than neatly designed system in
> 2014.

Will you have figured out how to work around similar
problems with all other dependency cases by 2014?
There are libraries in interpreted languages, static
libs, and just old programs that require old programs
to function.


More information about the freebsd-ports mailing list