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

[Raul Miller <moth@debian.org>]

I vote in favor of this resolution.

-- 
Raul

On Wed, Sep 15, 2004 at 11:32:01AM +0100, Ian Jackson wrote:
> (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.
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org