I submitted a PR for this (kind of) last week.  What I was thinking would
work was to either change the packages for things that are installed as
part of the base system to delete the pieces installed in the base system,
or to install these packages in the 'base' locations.
A good example is that some of the packages require OpenSSL MD4, which
isn't installed in the base system.  Adding OpenSSL's package leaves us
with one version of the openssl libs in /usr/lib, and another in
/usr/pkg/lib.  Sendmail, named, etc. have their own peculiarities.
>
>> > Hasn't a packagized base-system been promised?  I don't see it in
>> > 1.6 yet so would it probably be in -current/1.7 then?  IMHO having
>> > major parts of the base system under pkg control (things like
>> > various MTAs, OpenSSH etc.) would make some things a lot easier.
>>
>> I've heard discussion for such a system, but I wouldn't say it's been
>> "promised".  I agree it would be nice, but its non-trivial.  Managing
>> the dependancies, especially for people tracking -current or -release,
>> could rasie a whole bunch of problems.  I hope it can be made to work
>> though, but I wouldn't hold your breath.
>
> Could someone explain why it would emerge such a big problem? Having
> the  default stuff (sendmail, postfix, openssh etc) installed in their
> current  place, but as packages, or maybe having them in a specific
> default-packages  location, with LOCALBASE set to that, and having them
> initially recorded in  the package database shouldn't be that hard.
>
> And, as obvious, this would make for example upgrading such packages
> from  pkgsrc much easier...
>
> mortee


-- 
Dave Burgess
CTO, Nebraska On-Ramp
Chief Engineer, Mitec Internet Services
Bellevue, NE 68123