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. If we don't have access to code to test, or other
information, and no consultation, we can't allow ourselves to stop.
> [...] 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
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.
> 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, could perhaps compile on one machine
and ship linked binaries around.
- FChE
|