Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.java > #11673 > unrolled thread

Re: Issue about mutual dependencies for aparapi

Back to article view | Back to linux.debian.maint.java

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Issue about mutual dependencies for aparapi Andreas Tille <andreas@an3as.eu> - 2020-06-04 21:30 +0200
    Re: Issue about mutual dependencies for aparapi Mechtilde <ooo@mechtilde.de> - 2020-06-04 22:00 +0200
      Re: Issue about mutual dependencies for aparapi Thorsten Glaser <t.glaser@tarent.de> - 2020-06-04 22:40 +0200
        Re: Issue about mutual dependencies for aparapi Pierre Gruet <pgtdebian@free.fr> - 2020-06-05 23:40 +0200
          Re: Issue about mutual dependencies for aparapi Thorsten Glaser <t.glaser@tarent.de> - 2020-06-06 00:00 +0200

#11673 — Re: Issue about mutual dependencies for aparapi

[add debian-java to CC]

Hi Pierre,

thanks a lot for your continuous work to get snpeff packaged finally.
This is extremely welcome.

On Thu, Jun 04, 2020 at 05:49:23PM +0200, Pierre Gruet wrote:
> Hello everyone,
> 
> I am currently beginning packaging aparapi, which is a Java API to
> execute Java code on a GPU. In Debian Med, we need it as dependency of
> the dependency apfloat of SnpEff.
> 
> This package relies on a JNI (native code) package which the same
> upstream develops as aparapi-native.
> Yet aparapi and aparapi-native are somehow interleaved, as aparapi
> depends on aparapi-native *and* aparapi-native needs a small number of
> source files of aparapi to build. I understand upstream uses symlinks to
> solve this locally on their computers.
> 
> Having in mind Debian packaging, what would in your opinion be the best
> solution for us? We could:
> - build a package with multiple tarballs, which would provide both the
> JNI and Java binary packages;

I admit I **personally** avoid multiple source tarballs since it does
not work with gbp (at least this is my latest information - it might be
outdated.

> - use debian/missing-sources to add the few files that are needed by the
> JNI part and be able to build the two packages one after the other;

This would be my way to cope with this in case its some kind of a
limited amount of files.  Please provide a script that enables
easy updated of these sources.

> - another solution?

Alternatively you can write a debian/get-orig-source script which you
put as debian/rules get-orig-source target (I love separate scripts
since you have plain shell syntax without special meaning of $ and there
is no need to escape end of lines.

Here you can find two template examples for such a script:

   https://salsa.debian.org/med-team/community/package_template/-/tree/master/debian

I can not decide for what option I would finally decide without a deeper
inspection of the sources.  So I do not want to recommend any prefered
option.  Both are more or less equivalent in terms of effort and should
probably work similarly nice.  Feel free to keep on asking if the given
information is not yet sufficient to draw a final decision.

> Thanks a lot for your attention,

The thanks goes perfectly to you.

Kind regards

      Andreas. 

-- 
http://fam-tille.de

[toc] | [next] | [standalone]

#11674

[Multipart message — attachments visible in raw view] — view raw

Hello

Am 04.06.20 um 21:21 schrieb Andreas Tille:
> [add debian-java to CC]
> 
> Hi Pierre,
> 
> thanks a lot for your continuous work to get snpeff packaged finally.
> This is extremely welcome.
> 
> On Thu, Jun 04, 2020 at 05:49:23PM +0200, Pierre Gruet wrote:
>> Hello everyone,


> I admit I **personally** avoid multiple source tarballs since it does
> not work with gbp (at least this is my latest information - it might be
> outdated.

This is an outdated information. You can collect all source tar.gz
together in to one orig.tar.xz. In the d/gbp.conf you configure a
section components=[ '<first tar.gz>', '<second targz', '<and so on>',]

You can find the manpage under

https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/man.gbp.pristine.tar.html

Kind regards

-- 
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows und OS/2
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F

[toc] | [prev] | [next] | [standalone]

#11675

On Thu, 4 Jun 2020, Mechtilde wrote:

> This is an outdated information. You can collect all source tar.gz
> together in to one orig.tar.xz. In the d/gbp.conf you configure a

DON’T DO THAT.

MUTs (multi-origtgz) were invented for a good reason.

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”	(#nosec)    ‣‣‣ Please let MySQL and MariaDB finally die!

[toc] | [prev] | [next] | [standalone]

#11676

Hello,

Le 04/06/2020 à 22:36, Thorsten Glaser a écrit :
> On Thu, 4 Jun 2020, Mechtilde wrote:
> 
>> This is an outdated information. You can collect all source tar.gz
>> together in to one orig.tar.xz. In the d/gbp.conf you configure a
> 
> DON’T DO THAT.
> 
> MUTs (multi-origtgz) were invented for a good reason.
> 
> bye,
> //mirabilos
> 

Thanks to everyone for the advice and links about this issue! I
understand there are various solutions that can be implemented and are
valuable. I think I will first try gbp with a MUT package.

All the best,
Pierre

[toc] | [prev] | [next] | [standalone]

#11677

On Fri, 5 Jun 2020, Pierre Gruet wrote:

> valuable. I think I will first try gbp with a MUT package.

Your complimentary reminder that gbp is merely an add-on which
some packagers wish to use but not a standard Debian tool, and
things work very well without it. (In case gbp indeed still is
without support for MUT packages…)

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.java

csiph-web