Re: Pending issues with RELENG_5

On Mon, 27 Sep 2004, Jeremy Chadwick wrote:

> Here's a list of things that still concern me so far with RELENG_5,
> particularly with BETA6 (and even more recent than that).  Hopefully
> the appropriate parties can chime in here...

Since I happen to be the appropriate party for all of these, here you 
go. :)

> * No /etc/mergemaster.rc or /etc/defaults/mergemaster.rc
>  Possibly creating this out-of-the-box during install, or keep a
>  template in /etc/defaults/mergemaster.rc ?

Just like make.conf which you mentioned in a seperate mail,
/etc/defaults would not be the correct location for this. You really 
need to learn a bit more about -current/RELENG_5.

The man page for mergemaster actually has a commented out example of 
what you can specify in a mergemaster.rc file. My personal feeling is 
that there is not much utility in having an actual example file called 
mergemaster.rc, but I have repeatedly said that if someone wanted to 
send me some "cool mergemaster tricks" that they use, I would gladly 
convert them into something that could go into 
src/share/examples/etc/[mergemaster?]. To date, no one has done so.

What would be your goal for a mergemaster.rc file?

> * /etc/rc.d/named does not set up chroot environment properly
>  For example, in the chroot_autoupdate() function, lines 37
>  and 41 call pax blindly, referring to ${named_chrootdir}/dev even
>  if it hasn't been created.

As I have said repeatedly, chroot support for named is not yet complete. 
This is where reading the freebsd-current mailing list really comes in 
handy. I plan to get a lot closer to something that looks like full 
support very soon in -CURRENT, then it will be up to re_at_ whether to MFC 
it or not. Personally I would like to see it MFC'ed, but it's a "nice to 
have" compared to the BIND 9 import itself.

>  Could we get appropriate if [ -d ...]; then mkdir/chown/chmod; fi
>  statements for creating this structure?  I personally have no idea
>  who the appropriate directories should be owned by, or perm'd to.

The proper BSD solution to this is to use mtree, and I committed last 
night the mtree file that will be used as the basis of this part of the 
solution.

> * bind9 chroot tips
>  Possibly some details on how to configure named.conf inside the
>  default named.conf?  We hint at it already...

That is part of plan, yes.

> * Leftovers from bind8-->bind9 upgrade
>  We now have two versions of nslookup; /usr/bin/nslookup and
>  /usr/sbin/nslookup (deprecated), but we've also /usr/lib/libisc.*

Let's be more clear here. "We" don't have anything. If you have been 
upgrading from source, YOU have that stuff left over, as do a lot of 
other users. I think it's time that I repost my world cleaning tips ...

The chief concern at this stage is that a new install of 5.3-RELEASE has 
the right bits, and none of the wrong bits, and we are at that point 
now. If you are concerned about what can and cannot be deleted safely, 
your best bet is always to back up your data and do a clean install to a 
formatted disk.

>  I assume this can be deleted and ldconfig -R re-run?

Yes, but if you have ports that linked against this library you will 
have to rebuild them. Those issues should be discussed on the -ports 
list. This is almost sure to be a problem, but I don't think it will be 
a big one.

>  There's also the old dnsquery and dnskeygen binaries,

Delete them. You might also want to read src/UPDATING where you will 
find a complete list of binaries that have migrated. In fact, you should 
always read src/UPDATING when you upgrade.

>  extraneous manpages, etc..

I'll post my world cleaning tips later tonight, but the easiest way to 
deal with man pages is to just 'rm -r /usr/share/man' before doing 
installworld. You can also do 'mv /usr/include /usr/include-old' right 
before doing installworld to handle that similar situation.

>  [This entry could spawn off quite a long thread about how exactly we
>  plan on handling 'outdated' files.

No, it can't. You clearly have not been following the -current mailing 
list very long, as this topic comes up regularly. Check the archives.

> I was in a hurry this morning to get this out, meaning my actual "full
> list" is probably quite a bit longer... just need the time to sit down
> and type it all in.  :-)

I respectfully suggest that you spend a little more time researching the 
rest of your wish list before you send any more mail.

Doug

-- 

     This .signature sanitized for your protection