open-vm-tools in base

[Rodney W. Grimes]

> 
> 
> On Fri, Jan 10, 2020, at 12:38 PM, Steve Kargl wrote:
> > On Fri, Jan 10, 2020 at 10:44:38AM -0700, Warner Losh wrote:
> > > On Fri, Jan 10, 2020 at 10:26 AM Steve Kargl <
> > > sgk at troutmask.apl.washington.edu> wrote:
> > > 
> > > > On Fri, Jan 10, 2020 at 09:55:23AM -0600, Josh Paetzel wrote:
> > > > >
> > > > > There is some precedent for this.  Driver(s?) that were once a
> > > > >  part of the tools have been moved to base already.  The VMXNET3
> > > > > driver is an example of this.
> > > > >
> > > >
> > > > There is also precedent for removing a working driver from
> > > > base and putting it into ports.  See drm2.
> > > >
> > > 
> > > Not the best example to cite as there's been a lot of bumps with that and
> > > the future distribution model is unclear to me.
> > > 
> > 
> > Oddly enough I disagree. :-)
> > 
> > Does the problems for open-vm-tools occur in freebsd-stable,
> > where the kernel ABI should be stable?
> > 
> 
> HEAD breakage is most common.  There have been a few MFCs that have broken STABLE over the years but they are rare.
> 
> > Freebsd-current is the development tree, and kernel changes
> > might break 3rd party software.  drm2 is a perfect example.
> > In-base drm2 was working just fine and kept up-to-date with
> > kernel changes when it was attached to the build.  This seems
> > to be what Josh wants for open-vm-tools. 
> 
> Can you clarify which part of my proposal wasn't clear?  Or is "seem to want" just a conversational usage of language.
> 
>  > Once drm2 was detached
> > from the build it was ocassionally broken, and someone (often
> > times me) would find and report the breakage.  If open-vm-tools
> > is added to base, and then someone adds emulators/open-vm-tools-devel
> > which supercedes in-base open-vm-tool, we're back to the in-base drm2
> > situation.
> > 
> 
> I believe I addressed that in my initial email.  If there is a /usr/local version of the tools installed the user can select between the base system version and the "3rd party" install.
> 
> > Finally, open-vm-tools is used by what percentage of FreeBSD users?
> > 1%? 5%? 50%?
> > 
> 
> I don't believe we have the data to answer that.  I can give some ancillary data though:
> 
> When I was involved with FreeNAS ESXi was the single most popular platform to run it on, even though we straight out told people virtualizing FreeNAS wasn't recommended.  (At one point 30% of the ~100K systems that were phoning home were reporting ESXi as their hardware platform)
> 
> The last two places I've worked the virtualized FreeBSD instances outnumbered the on the iron FreeBSD systems by 10:1. (and one of those places was a hardware vendor that specialized in FreeBSD!)
> 
> My personal belief is that it could be greater than 50%.  That wouldn't surprise me.
> 
> However, since there is precisely zero downside to including the open-vm-tools in a hardware install, my counter question to you would be "what difference does the percentage make?"
> 
> I don't see an actual reason for an objection in your email.
> 
> We're not talking about changing the maintenance workload here, just shifting it around.

Perhaps rathan than have this argument over if this should be
moved to ports find a road map that stops, or atleast very
early identifies base system changes that cause breakage for
these heavly base system dependent ports (short list here
I am sure there are more:)
	drm2
	lsof
	open-vm-tools
	virtualbox

Building this short list of ports a few times a day
should be trivial for the CI infustructure.

As you stated the maintenance workload is invariant,
so all that is really neded is early identification.
 
And for pespective I run a lot of ESXi and FreeBSD guests... so
any bias I might have is in the wrong direction :-)

> > Steve
> Josh Paetzel
-- 
Rod Grimes                                                 rgrimes at freebsd.org