Date: Tue, 5 Jul 2011 16:36:02 +0200 From: Hans Ottevanger <hans@beastielabs.net> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-stable@freebsd.org Subject: Re: NFS related include files and make delete-old Message-ID: <20110705143602.GA93412@testsoekris.hotsoft.nl> In-Reply-To: <1457531349.170391.1309785527174.JavaMail.root@erie.cs.uoguelph.ca> References: <20110704085438.GA93119@testsoekris.hotsoft.nl> <1457531349.170391.1309785527174.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 04, 2011 at 09:18:47AM -0400, Rick Macklem wrote: > > Hi, > > > > For a few months now, during the usual make delete-old after > > make installworld the files > > > > /usr/include/nfs/krpc.h > > > > and > > > > /usr/include/nfs/nfsdiskless.h > > > > turn up time and again. I have them deleted, but they get reinstalled > > during the next make installworld. This is a fairly old installation, > > but running an up-to-date 8.2-STABLE and these header files are also > > present in the directory /usr/include/nfsclient. > > > I moved them from sys/nfsclient to sys/nfs, so that it would be more > obvious that they are shared by both NFS clients (in sys/nfsclient and > sys/fs/nfsclient). So the ones at the new location /usr/include/nfs would > not be deleted, the entry in ObsoleteFiles.inc that removed them from > /usr/include/nfs was deleted (by someone else, after discussing it with me). > At this moment make installworld only installs the headers in the new location, on both 8/stable and head/current. On 8/stable they are immediately removed again when running make delete-old, because they are in ObsoleteFiles.inc. On head/current they are left alone, they are not in ObsoleteFiles.inc (i.e. not anymore). If the files at the old location are still there, it is as a leftover from previous installations. On a freshly installed /usr/include hierarchy they will be missing. > I felt that they should remain in the old location for backwards compatibility. > (The "userland" contents of the two copies are identical, so it shouldn't matter > which copy any userland app includes. One problem here is that I have no idea > if any software outside of /usr/src includes these.) > I can confirm that the copies are identical (if they are present), apart from version control information. I think that you have to install the copies explicitly if you want them to be there, also on a fresh installs, for compatibility with 8.2-RELEASE and earlier. I would only do that for 8/stable, if at all. > > Could it be that either the wrong files are specified in > > /usr/src/ObsoleteFiles.inc or the headers are installed in the wrong > > directory during make installworld? > > > > On my 9.0-CURRENT systems I also have the headers at both locations, > > but there only those in /usr/include/nfsclient get reinstalled and > > there is no entry in /usr/src/ObsoleteFiles.inc. > > > Actually, only the ones in /usr/include/nfs should get updated, because they > now live in sys/nfs and not sys/nfsclient. I plan on adding an entry to > ObsoleteFiles.inc in head/current for the /usr/include/nfsclient ones. > (Thanks for the reminder w.r.t. this.) > Even as a relative outsider to the FreeBSD project I am all for it. I don't know the schedule for 9.0, but if anything breaks (e.g. in ports, not in /usr/src) it had better break now. > Should I MFC this to stable/8? > (I had assumed that I should leave them in > the old location for backwards compatibility and therefore wasn't going to > MFC deletion of them in /usr/include/nfsclient. If I MFC that, the entries > for them in ObsoleteFiles.inc for /usr/include/nfs need to be deleted, so > they remain in the new location.) > It would save you the effort of finding a way to actually install the copies at the old location. However, in a sense it would change the API, and I do not know how the keepers of the code tree think about that 8-) And, as already explained above, there is already an antry in ObsoleteFiles.inc on stable/8, but probably for the wrong directory. Kind regards, Hans Ottevanger
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110705143602.GA93412>