Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 Sep 2002 10:32:28 -0700
From:      Will Andrews <will@csociety.org>
To:        Maxim Sobolev <sobomax@FreeBSD.ORG>
Cc:        Will Andrews <will@csociety.org>, Simon 'corecode' Schubert <corecode@corecode.ath.cx>, Wes Peters <wes@softweyr.com>, ports@FreeBSD.ORG, arch@FreeBSD.ORG
Subject:   Re: package tools into ports/ (was: Re: Bzipped?)
Message-ID:  <20020903173228.GO2072@procyon.firepipe.net>
In-Reply-To: <20020903130237.GB8010@vega.vega.com>
References:  <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <20020903100258.068fb3ab.corecode@corecode.ath.cx> <20020903121413.GN2072@procyon.firepipe.net> <20020903130237.GB8010@vega.vega.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 03, 2002 at 04:02:37PM +0300, Maxim Sobolev wrote:
> I am also thinking about something like that for a quite some time,
> but it is not quite straightforward to implement correctly. Yes, you
> can add version reporting into pkg_info and make bsd.port.mk detecting
> it and installing a new version from ports if it is too outdated.
> 
> The problem with such approach is that if you will overwrite older
> versions in /usr/sbin with newer ones, it will work, but only until
> the next build/installworld (for example if user runs security branch
> and new patchlevel is available requiring full world rebuild), when
> the newer ones will be replaced by old ones again. Sure, executing
> `make something' in ports tree will put things in order again, but
> what if before that the user will try to delete some package or add
> a new one using pkg_delete/pkg_add directly?

Yes.. that was never my plan.

> Another approach is to install pkg_tools package into /usr/local, but
> extend tools in the base system to check version of their counterparts
> in /usr/local (if installed) and turn themselves into a wrappers if
> ones in /usr/local are newer than ones in the /usr. This approach is
> better in the long run, since it allows to not worry about system
> upgrades, but creates 'chiken and egg' problem, since adding
> checking/wrapping functionality would require to change pkg_install
> tools.

This wouldn't be a problem if PATH was set to give priority to
/usr/local and /usr/X11R6 over /usr.  Unfortunately, that is
another bug in FreeBSD.

The above solution could certainly help the situation, especially
for new users.

However, we can "workaround" it by hardcoding exec*()'s of other
pkg_* to their locations in /usr/local in the pkg_install port.

> Therefore, IMO some combined approach is necessary. I have the following
> (very preliminary) vision of what needs to be done to solve the
> problem:
> 
> 1. Assign some form of version number to pkg_install tools. This
> number should be monotonically increased each time when new
> functionality is added or older functionality used in bsd.port.mk
> is changed. Add appropriate reporting routine.

Agreed.

> 2. Add wrapping functionality into pkg_install tools: on startup
> of any tool check that a configuration file in some pre-defined
> location exsists, read it, compare versions here and there and
> execve() specified file if it is newer, otherwise continue running.
> Format of file could be very simple, say one line with two words:
> the first is version number and the second is installation base, i.e.
> /var/db/pkg_install.wrap:
> 
> 123455 /usr/local/sbin

Agreed.

> 3. Create an appropriate pkg_tools port, which will install latest
> version of the tools and generate configuration file described above
> when installed FreeBSD version supports finctionality described
> in (1). If it doesn't, then the port whould just overwrite versions of
> pkg tools in /usr/sbin with newer versions and warn user about the
> need to reinstall the port after buildworld/installworld.

The latest version is of some debate.  I think that people
installing from ports should get the -STABLE version, so that we
can still test things on -CURRENT.  After sufficient testing, MFC
the bits and regenerate the pkg_install tarball and update the port.

> 4. Add bsd.port.mk bits and pieces for installing that pkg_tools port
> if system version is too old.

Agreed.

> I hope that this would be useful for you. Any comments or questions
> are appreciated.

Yes, I think the procedure you have described here is optimal.
How about we divide up the task and meet back here?  Which ones
do you want to take?  I'll take the others.

Regards,
-- 
wca

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020903173228.GO2072>