Hey Frank,
----- Original Message -----
>
> Hi, Nathan -
>
> >> If the pcp sources we ship continue working, and our pmdas continue
> >> installing, that's good enough.
> >
> > No, thats not good enough IMO - we need to take steps to prevent
> > breakage to out of tree PMDAs too. There are very valid reasons
> > for being out-of-tree - like proprietary h/ware monitoring libs,
> > etc [...]
>
> Out-of-tree developers need to stay involved in the community, so we
> can know what their actual needs are, what the actual impact of
> changes would be.
Still no. We have no place putting demands on out-of-tree developers
in terms of what they "need" to do. We provide a mechanism which we've
documented as the Right Way to implement and install PMDAs and the onus
is 100% on us to now maintain that and not break anything in our stable
release series.
Think of the developers of PMDAs which extract instrumentation from an
in-house application, using some custom export (say, predating MMV) -
they have every reason to expect stable PCP upgrades to (continue to)
work. And they have no reason to expect to be involved with upstream
work to keep their existing setup working.
We can choose to redo this whole process (PMDA Install), but that then
becomes major (pcp v4, v5, ...) release material. This level of small
packaging issue is not the sort of thing I'd really want to trigger the
onset of such a major disruption to the installed base - the numbers
are all wrong. Small number of people care, relatively small advances,
but large numbers of people disrupted.
FWIW, the mindset I use is "if I had to do a live upgrade to thousands
of production machines with this new code, do I expect it to continue
to work everywhere? And/or would I be happy to get called at 2am (by
an annoyed, sleepy sysadmin colleague) to start fixing the potentially
catastrophic mess I just caused when it was rolled out?"
Then extend those questions beyond self, to cover every user of pcp on
this (stable) release series, and all of their deployment scenarios.
> If we don't have access to code to test, or other
> information, and no consultation, we can't allow ourselves to stop.
*nod* - definitely no need to stop - we even have one other possible
(and backward-compatible) solution here already, no doubt there are
others - we just need to be creative.
> > [...] those build files are part of the PMDA Install runtime for
> > some PMDAs.
>
> Identical files are permitted to be included in more than one RPM. So
> if some of these build-configuration files are required to just
> install a PMDA (btw does it have to be that way?), we could also
(for this stable release series, yes, it certainly does. for future
release series, wider consultation & discussion would be needed - but
sure, it could be changed)
> include those build-configuration files in the per-arch package that
> contains the PMDAs. Those are not -libs nor -libs-devel, so we don't
> have to worry about multi-lib issues.
Starting to sound a bit like that original plan I'd described ... I'll
experiment with something along those lines shortly, and report back.
> > I also overlooked the *link-only* requirements some PMDAs have had
> > in the past (database PMDAs were the classic case) - which means
> > that a full -devel install is not required to still make use of
> > builddefs and a PMDA makefile after all (as we thought yesterday).
> > -devel is a heavy-weight install too, so not a package I'd want as
> > part of every server install - we should not force that onto folks.
>
> For code that requires linking *or* full compilation, -devel
> requirements are traditional and appropriate. Folks stuck with such
> PMDAs, who cannot accept the 700 kilobytes of pcp-libs-devel but do
> accept 22 megabytes for binutils,
Or ... some other sizes - hey, pmdarpm will know! ;)
$ pminfo -f rpm.size | egrep '"coreutils|"pcp-libs-devel'
inst [863 or "pcp-libs-devel-3.8.13-1.x86_64"] value 1766815
inst [1002 or "coreutils-libs-8.4-19.el6.x86_64"] value 5576
inst [1656 or "coreutils-8.4-19.el6.x86_64"] value 12847030
> ... could perhaps compile on one machine and ship linked binaries
> around.
*nod* - good points indeed. The mentality may have originated in
old-skool Unixen (IRIX) where the linker was always available but
not necessarily an entire cc toolchain (and cc was licensed, as in
"fork out cash to use it"). Anyway, all academic at this stage...
it turns out moving builddefs & co into -libs-devel doesn't help
us after all - we're requested to make -libs-devel multilib also
(which introduces other, different challenges).
Thanks for the input!
cheers.
--
Nathan
|