Re: Bug#266837: rpvm_0.6.2-1_hppa: FTBFS: relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC
Thanks to Raul, Bdale and Steinar for comments and suggestions. At
Bdale's request I have deleted the old paragraph 17 (which
contemplated the rpvm maintainer closing their bug). So ...
I hereby propose the following resolution and call for an immediate vote:
It appears that everyone agrees on the following set of facts:
1. rpvm, an extension for integrating GNU R with PVM, uses a library
libgpvm3 from pvm.
2. This library is currently in pvm's .deb only as a .a containing
non-PIC code. This is a historical accident and not intended to
be the permanent behaviour; it should be changed eventually.
3. R expects extensions to be shared libraries and rpvm should not be
an exception to this.
4. On architectures other than i386 and ARM, shared libraries cannot
contain non-PIC code.
5. For the reasons above, rpvm has never worked properly (upstream,
or Debian) on architectures other than i386 and ARM.
Disputed questions include:
6. Should pvm be changed to ship libgpvm3_pic.a or a suitable .so, for
sarge, so that a working rpvm can be made available in sarge on
all architectures ?
7. What should be done with the bug reports ?
We note that:
8. While the Technical Committee is not the official arbiter of
process questions such as the proper use of the bug system, we
have been asked for our opinion and it would be helpful of us to
9. It is not clear how difficult or risky the change would be to make
pvm build a suitable library. It is difficult for the Committee
to evaluate this, without a suitable patch to review.
10. The pvm maintainer is a volunteer is not obliged to do the
technical work necessary to support rpvm.
11. Nothing in the release policy requires or forbid the relevant
changes to pvm or rpvm at this stage of the release process.
We therefore conclude that:
12. There are (perhaps) two distinct sets of changes required to fix
this problem; the changes to pvm to supply a suitable library,
and any changes to rpvm to make use of the new library. And, of
course, there are two packages which have some kind of defect.
Therefore it is not inappropriate for there to be two bug reports
13. Since rpvm has never been supported other than on i386 and ARM we
believe that the current release policy would make the problem
non-release-critical for rpvm. We believe the problem is
non-release-critical for pvm.
14. As the maintainer of each package is a volunteer, they have the
freedom to direct their effort as they see fit. Additionally it
is proper for the maintainer to have a strong influence on the
perceptions of other developers regarding the best use of effort
spent on the package. The bug system severities provide a
suitable way to manage this process. For non-release-critical
bugs, the severity should therefore usually be assigned with free
discretion by the maintainer.
We therefore recommend that:
15. There should be two open bugs regarding this issue, as follows:
#266837 against rpvm regarding the missing architectures, and
#266762 against pvm regarding the missing library. These bugs
should have whatever severity the respective package maintainer
assigns from time to time.
16. The rpvm maintainer should (if they see fit and are able) prepare
a suitable patch to pvm to arrange for the supply of the
necessary library. Such a patch should be reported to the pvm
maintainer via the existing bug.
17. If such a patch is made available the pvm maintainer should
evaluate its suitability for inclusion in sarge. If the pvm
maintainer decides not to include the patch in sarge, or does not
respond in a timely manner, then the Committee encourages the
rpvm maintainer to bring the matter to our attention, and we will
consider whether to overrule the maintainer and direct that the
patch should be included in sarge.
18. We do not rule out alternative technical solutions which the rpvm
maintainer may choose to implement. Nevertheless, no such
solution entitles the rpvm maintainer to /mandate/ any change in
pvm, or to fight with the pvm maintainer over the severities of
19. The Committee's decisions here regarding the releasability of
various packages are not to be construed as overruling or
directing the Release Team.
20. The Committee's decisions here regarding the proper use of the
bug system are not to be construed as overruling the BTS
21. Therefore, if the Release Team or BTS maintainers disagree with
the Committee's decisions here we encourage them to contact us
immediately, and the Release Team's or BTS maintainers'
instructions will stand during any subsequent discussion.