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

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

wanting to join the java team

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

Contents

  wanting to join the java team Carnë Draug <carandraug+dev@gmail.com> - 2017-07-10 16:50 +0200
    Re: wanting to join the java team Markus Koschany <apo@debian.org> - 2017-07-10 17:50 +0200
      Re: wanting to join the java team Carnë Draug <carandraug+dev@gmail.com> - 2017-07-11 19:00 +0200
        Re: wanting to join the java team Markus Koschany <apo@debian.org> - 2017-07-13 22:00 +0200
          Re: wanting to join the java team Thorsten Glaser <t.glaser@tarent.de> - 2017-07-14 10:00 +0200
          Re: wanting to join the java team Carnë Draug <carandraug+dev@gmail.com> - 2017-07-14 18:00 +0200
            Re: wanting to join the java team Markus Koschany <apo@debian.org> - 2017-07-14 20:20 +0200
              Re: wanting to join the java team Carnë Draug <carandraug+dev@gmail.com> - 2017-07-14 22:30 +0200
                Re: wanting to join the java team Markus Koschany <apo@debian.org> - 2017-07-16 23:50 +0200
                  Re: wanting to join the java team Carnë Draug <carandraug+dev@gmail.com> - 2017-07-27 18:00 +0200
                    Re: wanting to join the java team Markus Koschany <apo@debian.org> - 2017-07-27 18:00 +0200
                      Re: wanting to join the java team Carnë Draug <carandraug+dev@gmail.com> - 2017-07-29 17:00 +0200
                        Re: wanting to join the java team Markus Koschany <apo@debian.org> - 2017-07-29 17:10 +0200
                          Re: wanting to join the java team Carnë Draug <carandraug+dev@gmail.com> - 2017-09-28 13:50 +0200
                            Re: wanting to join the java team Markus Koschany <apo@debian.org> - 2017-09-28 18:00 +0200
                              Review of fairsim, libjtransforms-java and libjlargearray-java Markus Koschany <apo@debian.org> - 2017-10-02 01:30 +0200
                                Re: Review of fairsim, libjtransforms-java and libjlargearray-java Emmanuel Bourg <ebourg@apache.org> - 2017-10-02 23:00 +0200
                                  Re: Review of fairsim, libjtransforms-java and libjlargearray-java Markus Koschany <apo@debian.org> - 2017-10-03 19:40 +0200
                                Re: Review of fairsim, libjtransforms-java and libjlargearray-java Emmanuel Bourg <ebourg@apache.org> - 2017-10-02 23:20 +0200
                                  Re: Review of fairsim, libjtransforms-java and libjlargearray-java Markus Koschany <apo@debian.org> - 2017-10-02 23:50 +0200
                                Re: Review of fairsim, libjtransforms-java and libjlargearray-java Carnë Draug <carandraug+dev@gmail.com> - 2017-10-03 17:40 +0200
                                  Re: Review of fairsim, libjtransforms-java and libjlargearray-java Markus Koschany <apo@debian.org> - 2017-10-03 19:20 +0200
                                    Re: Review of fairsim, libjtransforms-java and libjlargearray-java Carnë Draug <carandraug+dev@gmail.com> - 2017-10-04 17:50 +0200
                                      Re: Review of fairsim, libjtransforms-java and libjlargearray-java Markus Koschany <apo@debian.org> - 2017-10-04 19:20 +0200
                                        Re: Review of fairsim, libjtransforms-java and libjlargearray-java Carnë Draug <carandraug+dev@gmail.com> - 2017-10-05 13:10 +0200
                                          Re: Review of fairsim, libjtransforms-java and libjlargearray-java Markus Koschany <apo@debian.org> - 2017-10-05 14:40 +0200

Page 1 of 2  [1] 2  Next page →

#9788 — wanting to join the java team

Hi

I am interested joining the Debian java team and package a series of
java applications.  The long term goal is to package bioformats [1]
and OMERO [2] altough I will start by packaging their dependencies.

I have packaged a series of perl distributions before with the perl
team so while new to packaging java libraries, I am not completely new
to Debian packaging.

The java libraries I will package are useful for myself at work where
I maintain a series of Debian systems where I need them.  I won't just
package them once and run away ;)

I have an alioth account carandraug-guest.  Could I be added to the
team please?

Thank you
Carnë

[toc] | [next] | [standalone]

#9789

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

Forgot to CC the list.

Hello Carnë,

welcome to the list. Please consider to subscribe!

Am 10.07.2017 um 16:41 schrieb Carnë Draug:
> Hi
> 
> I am interested joining the Debian java team and package a series of
> java applications.  The long term goal is to package bioformats [1]
> and OMERO [2] altough I will start by packaging their dependencies.

Links are missing. :)

> I have packaged a series of perl distributions before with the perl
> team so while new to packaging java libraries, I am not completely new
> to Debian packaging.
> 
> The java libraries I will package are useful for myself at work where
> I maintain a series of Debian systems where I need them.

>  I won't just
> package them once and run away ;)

Hear, Hear.

> I have an alioth account carandraug-guest.  Could I be added to the
> team please?

I suggest that you start with packaging your libraries and upload them
to Debian Mentors [1] where they can be reviewed by us. Just post your
questions on this list, if you need help. In a final step, when
everything looks ready to upload, we can grant you access to pkg-java.
By the way there is also the Debian Science team that focuses on
packaging bioinformatics apps among others.

Regards,

Markus

[1] https://mentors.debian.net/intro-maintainers

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

#9792

On 10 July 2017 at 16:47, Markus Koschany <apo@debian.org> wrote:
> Forgot to CC the list.
>
> Hello Carnë,
>
> welcome to the list. Please consider to subscribe!
>
> Am 10.07.2017 um 16:41 schrieb Carnë Draug:
>> Hi
>>
>> I am interested joining the Debian java team and package a series of
>> java applications.  The long term goal is to package bioformats [1]
>> and OMERO [2] altough I will start by packaging their dependencies.
>
> Links are missing. :)

Ups.  Here they are:

[1] http://www.openmicroscopy.org/site/products/bio-formats
[2] http://www.openmicroscopy.org/site/products/omero

>> I have an alioth account carandraug-guest.  Could I be added to the
>> team please?
>
> I suggest that you start with packaging your libraries and upload them
> to Debian Mentors [1] where they can be reviewed by us. Just post your
> questions on this list, if you need help. In a final step, when
> everything looks ready to upload, we can grant you access to pkg-java.
> By the way there is also the Debian Science team that focuses on
> packaging bioinformatics apps among others.
>
> Regards,
>
> Markus
>
> [1] https://mentors.debian.net/intro-maintainers

Ok.  I finished my first java package for debian and uploaded it to
debian mentors [3].  Could someone take a look at it?  That page says
that the watch file does not work but that is because I am using
version 4 of the format.  I have also put the git repository used for
the build online [4].

Thank you
Carnë

[3] https://mentors.debian.net/package/libjlargearrays-java
[4] https://github.com/carandraug/debian-libjlargearrays-java

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

#9794

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

Am 11.07.2017 um 18:57 schrieb Carnë Draug:
[...]
> Ok.  I finished my first java package for debian and uploaded it to
> debian mentors [3].  Could someone take a look at it?  That page says
> that the watch file does not work but that is because I am using
> version 4 of the format.  I have also put the git repository used for
> the build online [4].

The package looks good to me if you fix the following:

debian/control: Standards-Version is 4.0.0 now.

debian/copyright: It is recommended to use the secure https:// link

Lintian doesn't like the short description of your -doc package.

Java·library·for·one·dimensional·arrays·up·to·2^63·elements

I suggest to change the short description simply to

Documentation of libjlargearrays-java

which is in line with most Maven packages.

Lintian is a valuable tool to spot these kind of issues. I recommend to
use the following configuration options in ~/.config/lintian/lintianrc

info=yes
display-info=yes
display-experimental=yes
pedantic=yes
show-overrides=yes
color=auto
verbose=yes

All in all very good job for your first Java package.

Regards,

Markus

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

#9797

On Thu, 13 Jul 2017, Markus Koschany wrote:

> Lintian doesn't like the short description of your -doc package.
> 
> Java·library·for·one·dimensional·arrays·up·to·2^63·elements

That’s probably because it has · instead of spaces…

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] | [next] | [standalone]

#9798

On 13 July 2017 at 20:59, Markus Koschany <apo@debian.org> wrote:
> Am 11.07.2017 um 18:57 schrieb Carnë Draug:
> [...]
>> Ok.  I finished my first java package for debian and uploaded it to
>> debian mentors [3].  Could someone take a look at it?  That page says
>> that the watch file does not work but that is because I am using
>> version 4 of the format.  I have also put the git repository used for
>> the build online [4].
>
> The package looks good to me if you fix the following:
>
> debian/control: Standards-Version is 4.0.0 now.
>
> debian/copyright: It is recommended to use the secure https:// link
>
> Lintian doesn't like the short description of your -doc package.
>
> Java·library·for·one·dimensional·arrays·up·to·2^63·elements
>
> I suggest to change the short description simply to
>
> Documentation of libjlargearrays-java
>
> which is in line with most Maven packages.

The problem with the sort description was that I was running emacs
remotely inside screen.  When I copied paste that sentence, it came
with the character that emacs uses to show whitespace.

> Lintian is a valuable tool to spot these kind of issues. I recommend to
> use the following configuration options in ~/.config/lintian/lintianrc
>
> info=yes
> display-info=yes
> display-experimental=yes
> pedantic=yes
> show-overrides=yes
> color=auto
> verbose=yes
>

I did use lintian with:

  lintian --pedantic -i -I -E --show-overrides \
    ../libjlargearrays-java_1.6-1_source.changes

but all it complained about was not using gpg signature for the watch
file.  I guess the lintian checks are different on sid (I'm running
stretch)?

I will fix those issues.  Should I then use debian.mentors again?  On
the perl team, changing the distribution to unstable moves them to
"Ready for Upload" queue in the team PET and that's how one would
request review and upload.

Carnë

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

#9799

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

Am 14.07.2017 um 17:49 schrieb Carnë Draug:
[...]
> The problem with the sort description was that I was running emacs
> remotely inside screen.  When I copied paste that sentence, it came
> with the character that emacs uses to show whitespace.

Yes, I thought so. No worries though. You can either replace those
characters with whitespace or just shorten the description to the
sentence I have suggested which is completely fine.

[...]

> I did use lintian with:
> 
>   lintian --pedantic -i -I -E --show-overrides \
>     ../libjlargearrays-java_1.6-1_source.changes
> 
> but all it complained about was not using gpg signature for the watch
> file.  I guess the lintian checks are different on sid (I'm running
> stretch)?

Indeed the versions of Lintian differ from distribution to distribution.
I strongly recommend to build everything in a sid/unstable environment
where you also get the latest Lintian. The schroot [1] tool is very
useful if you usually run something else than unstable. As for myself I
run the testing distribution and use several different s(chroots) to
build my packages.

> I will fix those issues.  Should I then use debian.mentors again?  On
> the perl team, changing the distribution to unstable moves them to
> "Ready for Upload" queue in the team PET and that's how one would
> request review and upload.

Interesting suggestion. We haven't used PET that much in our team so
far. For us requesting sponsorship on debian-java just worked very well.
I suggest to use mentors again for all initial packaging. As soon as we
have completed this stage you can use the pkg-java Git repositories and
mentors will become redundant.

So here is the deal. I intend to sponsor your packages, if they are of
the same quality as libjlargearrays-java. Though I suggest to prepare
all packages on your local system before we start to upload them to
Debian. To speed up the process you can also send an overview to this
list, what and how many packages you intend to upload in the end. This
should ensure that we don't accidentally upload packages which are not
really needed or are already part of Debian with a different name.

Regards,

Markus

[1] https://wiki.debian.org/Schroot

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

#9804

On 14 July 2017 at 19:11, Markus Koschany <apo@debian.org> wrote:
> Am 14.07.2017 um 17:49 schrieb Carnë Draug:
> [...]
>> I will fix those issues.  Should I then use debian.mentors again?  On
>> the perl team, changing the distribution to unstable moves them to
>> "Ready for Upload" queue in the team PET and that's how one would
>> request review and upload.
>
> Interesting suggestion. We haven't used PET that much in our team so
> far. For us requesting sponsorship on debian-java just worked very well.
> I suggest to use mentors again for all initial packaging. As soon as we
> have completed this stage you can use the pkg-java Git repositories and
> mentors will become redundant.

Just for information, the way it works in pkg-perl once part of the
team, I would change distribution to unstable which signal a review
via PET.  A DD would then review it and either upload it or revert
back to UNRELEASED and leave comments as TODO notes on d/changelog.

I don't mind either way, mailing list is fine.  It's just that the
pkg-perl is the only one I had packages with thus far.

> So here is the deal. I intend to sponsor your packages, if they are of
> the same quality as libjlargearrays-java. Though I suggest to prepare
> all packages on your local system before we start to upload them to
> Debian. To speed up the process you can also send an overview to this
> list, what and how many packages you intend to upload in the end. This
> should ensure that we don't accidentally upload packages which are not
> really needed or are already part of Debian with a different name.

I don't have a total list of packages I will package.  I have a list
of final packages that I want but I am aware that will involve package
all of their dependencies first.  The final packages that I expect
take me the most time are Bioformats [2], and OMERO [3] which I
mentioned on my original post.  In addition, I want to package FairSIM
[4], and SIMCheck [5].

OMERO is a pretty complex program so I want to leave it to the end
when I'm more familiar with java packaging.  Bioformats is simpler but
still has many components and some tricky dependencies (they have
bundled and forked some of their dependencies).

So I am packaging FairSIM first.  This is dependent on JTransforms [6]
which is dependent on JLargeArrays [7] which is what I am packaging at
the moment.  I am at the same time packaging ome-common-java [8] which
is one the first bioformats dependencies.

I would prefer to have each packaged reviewed as I prepare them. This
would prevent me from doing a mistake on all packages.  I would get
feedback when I do it the first time, and I would already prevent on
future work.

Cheers,
Carnë

> Regards,
>
> Markus
>
> [1] https://wiki.debian.org/Schroot

[2] http://www.openmicroscopy.org/site/products/bio-formats
[3] http://www.openmicroscopy.org/site/products/omero
[4] http://fairsim.github.io/
[5] http://www.micron.ox.ac.uk/microngroup/software/SIMcheck.html
[6] https://sites.google.com/site/piotrwendykier/software/jtransforms
[7] https://gitlab.com/ICM-VisLab/JLargeArrays
[8] https://github.com/ome/ome-common-java

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

#9807

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

Am 14.07.2017 um 22:24 schrieb Carnë Draug:
[...]
> So I am packaging FairSIM first.  This is dependent on JTransforms [6]
> which is dependent on JLargeArrays [7] which is what I am packaging at
> the moment.  I am at the same time packaging ome-common-java [8] which
> is one the first bioformats dependencies.
> 
> I would prefer to have each packaged reviewed as I prepare them. This
> would prevent me from doing a mistake on all packages.  I would get
> feedback when I do it the first time, and I would already prevent on
> future work.

Hi,

that's fine with me. FairSIM seems to be a good choice for starters.
Just ask for review on the list again and I or someone else will take a
look at it.

Cheers,

Markus

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

#9835

On 16 July 2017 at 22:39, Markus Koschany <apo@debian.org> wrote:
> Am 14.07.2017 um 22:24 schrieb Carnë Draug:
> [...]
>> So I am packaging FairSIM first.  This is dependent on JTransforms [6]
>> which is dependent on JLargeArrays [7] which is what I am packaging at
>> the moment.  I am at the same time packaging ome-common-java [8] which
>> is one the first bioformats dependencies.
>>
>> I would prefer to have each packaged reviewed as I prepare them. This
>> would prevent me from doing a mistake on all packages.  I would get
>> feedback when I do it the first time, and I would already prevent on
>> future work.
>
> Hi,
>
> that's fine with me. FairSIM seems to be a good choice for starters.
> Just ask for review on the list again and I or someone else will take a
> look at it.
>
> Cheers,
>
> Markus

I have repackaged JLargeArrays addressing the issues from the last
time.  Could someone take a new look?

https://mentors.debian.net/package/libjlargearrays-java

Thank you
Carnë

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

#9836

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

Am 27.07.2017 um 17:49 schrieb Carnë Draug:
[...]
> I have repackaged JLargeArrays addressing the issues from the last
> time.  Could someone take a new look?
> 
> https://mentors.debian.net/package/libjlargearrays-java
> 

Looks good.

Regards,

Markus

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

#9841

On 27 July 2017 at 16:55, Markus Koschany <apo@debian.org> wrote:
> Am 27.07.2017 um 17:49 schrieb Carnë Draug:
> [...]
>> I have repackaged JLargeArrays addressing the issues from the last
>> time.  Could someone take a new look?
>>
>> https://mentors.debian.net/package/libjlargearrays-java
>>
>
> Looks good.
>
> Regards,
>
> Markus

So do I need to do something else to have that package uploaded to the
NEW queue?

I have also noticed that the Vcs-Browser and Vcs-Git on the d/control
file are incorrect.  Could someone create a git repository on the
pkg-java and then I would fix that?

Thank you
Carnë

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

#9842

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

Am 29.07.2017 um 16:57 schrieb Carnë Draug:
> On 27 July 2017 at 16:55, Markus Koschany <apo@debian.org> wrote:
>> Am 27.07.2017 um 17:49 schrieb Carnë Draug:
>> [...]
>>> I have repackaged JLargeArrays addressing the issues from the last
>>> time.  Could someone take a new look?
>>>
>>> https://mentors.debian.net/package/libjlargearrays-java
>>>
>>
>> Looks good.
>>
>> Regards,
>>
>> Markus
> 
> So do I need to do something else to have that package uploaded to the
> NEW queue?

Hello,

I thought you wanted to package FairSIM first and its dependencies. As
soon as this is done, I will take a look at them and then upload all
packages together.

> I have also noticed that the Vcs-Browser and Vcs-Git on the d/control
> file are incorrect.  Could someone create a git repository on the
> pkg-java and then I would fix that?

The Vcs-URI looks correct to me. The repository has not been created
though. We will complete this step when all packages are ready and then
you could join the team manage all Git related tasks yourself next time.

Regards,

Markus

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

#10040

On 29 July 2017 at 16:08, Markus Koschany <apo@debian.org> wrote:
> Am 29.07.2017 um 16:57 schrieb Carnë Draug:
>> On 27 July 2017 at 16:55, Markus Koschany <apo@debian.org> wrote:
>>> Am 27.07.2017 um 17:49 schrieb Carnë Draug:
>>> [...]
>>>> I have repackaged JLargeArrays addressing the issues from the last
>>>> time.  Could someone take a new look?
>>>>
>>>> https://mentors.debian.net/package/libjlargearrays-java
>>>>
>>>
>>> Looks good.
>>>
>>> Regards,
>>>
>>> Markus
>>
>> So do I need to do something else to have that package uploaded to the
>> NEW queue?
>
> Hello,
>
> I thought you wanted to package FairSIM first and its dependencies. As
> soon as this is done, I will take a look at them and then upload all
> packages together.
>
>> I have also noticed that the Vcs-Browser and Vcs-Git on the d/control
>> file are incorrect.  Could someone create a git repository on the
>> pkg-java and then I would fix that?
>
> The Vcs-URI looks correct to me. The repository has not been created
> though. We will complete this step when all packages are ready and then
> you could join the team manage all Git related tasks yourself next time.
>
> Regards,
>
> Markus

I have finally packaged fairsim and uploaded it to d.mentors [1].  It
requires two other packages, JLargeArrays and JTransforms, both of
which I have also uploaded to d.mentors [2, 3].  Could you please
review them?

Took me a while because it also required some work on the imagej
package (de facto abandoned but still in debian-med).  I also
struggled with the right maven incantations to build the javadocs
correctly.

I have one last minor issue with maven that I can't fix.  I would like
to patch one of the java files in fairsim.  However, because it uses
the root of the package as sourceDirectory, the copies made by quilt
in .pc are found by the java compiler which then errors due to a
duplicated class.  I workaround this by not applying any patch.  The
two I would like to apply is a javadoc fix (already reported upstream
[4]), and the text on the about window which mentions the git checksum
from the build to report bugs (it should mention debian instead).

Carnë

[1] https://mentors.debian.net/package/fairsim
[2] https://mentors.debian.net/package/libjlargearrays-java
[3] https://mentors.debian.net/package/libjtransforms-java
[4] https://github.com/fairSIM/fairSIM/pull/17

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

#10041

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

Am 28.09.2017 um 13:39 schrieb Carnë Draug:
[...]
> I have finally packaged fairsim and uploaded it to d.mentors [1].  It
> requires two other packages, JLargeArrays and JTransforms, both of
> which I have also uploaded to d.mentors [2, 3].  Could you please
> review them?

[...]

Hello Carnë,

I will review your package soon.

Regards,

Markus

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

#10049 — Review of fairsim, libjtransforms-java and libjlargearray-java

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

Hi,

I think all three packages are in a good shape but there are some issues.

Standards-Version is 4.1.1 now.

I suggest to remove the -doc packages because I don't believe those
libraries are significant enough to warrant the maintenance of
additional documentation packages but I leave the decision to you. That
would also simplify the packaging a little.

You don't have to add the classpath to the library. The Lintian check
that warned about this issue has recently been removed. If you do it and
use jh_classpath or the *.classpath file then you must specify the
absolute path to the libraries otherwise they won't be found. In general
you rarely need both javahelper and maven-debian-helper in one package.
I believe maven-debian-helper would suffice here and you can remove the
build-dependency on javahelper and the related substvars.

I also suggest to remove the --has-package-version flag from the *.poms
files. There was a recent change in maven-debian-helper that
automatically adds a versioned dependency to reverse-dependencies if one
of their build-dependencies uses this flag. In my opinion in most cases
this is too strict and not what you probably wanted.

Regarding your failing patch I'm not sure. It doesn't sound like it is
Java specific. You can send me your patch and I can take a look though.

Regards,

Markus

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

#10050 — Re: Review of fairsim, libjtransforms-java and libjlargearray-java

Le 2/10/2017 à 17:51, Markus Koschany a écrit :

> There is at least one major downside of the current behavior. You
> completely loose the flexibility to choose that your package is able to
> run with an older version of libfoo. There is always a strict dependency
> on the latest version which can be a real hassle if you try to backport
> packages. Unfortunately we don't have a C/C++ mechanism like symbols
> files in Java but the answer should not be to enforce a dependency on
> the latest version.

Ideally the version used for the resolved dependencies should be the
ones defined in the pom, such that the packages express the same
requirements than the Maven artifacts they contain. That would be a less
strict middle ground.

Regarding the backports, what the current maven-debian-helper behavior
really limits is the ability to download a .deb built for sid and
install it directly in stable. Rebuilding the package for stable is
still possible with no extra modification, and the resolved dependencies
will then refer to the versions in stable.

Emmanuel Bourg

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

#10060 — Re: Review of fairsim, libjtransforms-java and libjlargearray-java

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

Am 02.10.2017 um 18:35 schrieb Emmanuel Bourg:
> Le 2/10/2017 à 17:51, Markus Koschany a écrit :
> 
>> There is at least one major downside of the current behavior. You
>> completely loose the flexibility to choose that your package is able to
>> run with an older version of libfoo. There is always a strict dependency
>> on the latest version which can be a real hassle if you try to backport
>> packages. Unfortunately we don't have a C/C++ mechanism like symbols
>> files in Java but the answer should not be to enforce a dependency on
>> the latest version.
> 
> Ideally the version used for the resolved dependencies should be the
> ones defined in the pom, such that the packages express the same
> requirements than the Maven artifacts they contain. That would be a less
> strict middle ground.

In my opinion this should have been a new option where users can choose
to opt-in. I find it less than optimal that the behavior of an existing
option was changed without further notice and documentation and now
everyone is expected to cope with the situation.

> Regarding the backports, what the current maven-debian-helper behavior
> really limits is the ability to download a .deb built for sid and
> install it directly in stable.

That would be an interesting feature but I think it is unrelated to the
problem at hand.

 Rebuilding the package for stable is
> still possible with no extra modification, and the resolved dependencies
> will then refer to the versions in stable.

Ok, this is true. But the dependency will be >= the latest version in
backports or stable. This makes it more complicated to use customized
packages. In the end the user is forced to override the strict
dependency in debian/control if he prefers to use an earlier package
version.

Markus

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

#10051 — Re: Review of fairsim, libjtransforms-java and libjlargearray-java

Le 2/10/2017 à 01:21, Markus Koschany a écrit :

> I also suggest to remove the --has-package-version flag from the *.poms
> files. There was a recent change in maven-debian-helper that
> automatically adds a versioned dependency to reverse-dependencies if one
> of their build-dependencies uses this flag. In my opinion in most cases
> this is too strict and not what you probably wanted.

Regarding the --has-package-version flag, my recommendation is to keep
it unless the version of the package doesn't match the version of the
pom. The versioned dependency added by maven-debian-helper is good for
ensuring consistent transitions to testing automatically (that is, if
libfoo-java requires libbar-java 2.0 but is ready before libbar-java for
a transition to testing, the versioned dependency holds libfoo-java in
unstable until libbar-java is ready to transition as well.).

Emmanuel Bourg

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

#10054 — Re: Review of fairsim, libjtransforms-java and libjlargearray-java

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

Am 02.10.2017 um 17:22 schrieb Emmanuel Bourg:
> Le 2/10/2017 à 01:21, Markus Koschany a écrit :
> 
>> I also suggest to remove the --has-package-version flag from the *.poms
>> files. There was a recent change in maven-debian-helper that
>> automatically adds a versioned dependency to reverse-dependencies if one
>> of their build-dependencies uses this flag. In my opinion in most cases
>> this is too strict and not what you probably wanted.
> 
> Regarding the --has-package-version flag, my recommendation is to keep
> it unless the version of the package doesn't match the version of the
> pom. The versioned dependency added by maven-debian-helper is good for
> ensuring consistent transitions to testing automatically (that is, if
> libfoo-java requires libbar-java 2.0 but is ready before libbar-java for
> a transition to testing, the versioned dependency holds libfoo-java in
> unstable until libbar-java is ready to transition as well.).

There is at least one major downside of the current behavior. You
completely loose the flexibility to choose that your package is able to
run with an older version of libfoo. There is always a strict dependency
on the latest version which can be a real hassle if you try to backport
packages. Unfortunately we don't have a C/C++ mechanism like symbols
files in Java but the answer should not be to enforce a dependency on
the latest version.

Markus

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web