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

[Ian Jackson <ian@davenant.greenend.org.uk>]

(I accidentally failed to send my last message to the committee list.
My apologies!  Here is a slightly edited version, taking into account
a correction from Steinar.)

It looks like informal discussions aren't doing the job here.  I
hereby propose the resolution below.  If anyone disagrees with any of
the facts I claim are undisputed, or I seem to have missed something,
then please let me know and I'll withdraw and amend it.

 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
     give guideance.

  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
     open.

 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. If the rpvm maintainer is of the opinion that there is no change
     needed to rpvm to fix the problem - ie, that the problem will be
     fixed automatically when the missing library is provided by pvm -
     then the rpvm maintainer may, if they wish, close their bug or
     merge it with the pvm bug.  During this process the severity
     settings of bug(s) against pvm should be retained, so that bugs
     against each package have the severity assigned by the maintainer
     of that package.

 17. 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.

 18. 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.

 19. 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
     pvm bugs.

 However:

 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
     maintainers.

 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.

Ian.