Date: Wed, 4 Sep 2002 01:16:13 +0300 From: Maxim Sobolev <sobomax@FreeBSD.ORG> To: 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: <20020903221613.GC9384@vega.vega.com> In-Reply-To: <20020903173228.GO2072@procyon.firepipe.net> 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> <20020903173228.GO2072@procyon.firepipe.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 03, 2002 at 10:32:28AM -0700, Will Andrews wrote: > 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. I could take src/usr.sbin/pkg_install part, leaving bsd.port.mk and actual pkg_tools (pkg_install?) port to you. -Maxim 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?20020903221613.GC9384>