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

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

The transition to BND 2.x

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

Contents

  The transition to BND 2.x Markus Koschany <apo@gambaru.de> - 2015-06-06 14:50 +0200
    Re: The transition to BND 2.x Emmanuel Bourg <ebourg@apache.org> - 2015-06-11 13:00 +0200
      Re: The transition to BND 2.x Markus Koschany <apo@gambaru.de> - 2015-06-16 20:40 +0200
        Re: The transition to BND 2.x Emmanuel Bourg <ebourg@apache.org> - 2015-06-16 23:40 +0200
          Re: The transition to BND 2.x Markus Koschany <apo@gambaru.de> - 2015-06-17 01:20 +0200

#8066 — The transition to BND 2.x

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

Hi,

status e-mail about the transition to BND 2.x. It appears I was a bit
too optimistic and I don't think that I can fix all r-deps of bnd at
once. Thus I have fixed the FTBFS of bnd 1.50 in sid because we need
this version probably a little while longer.

I propose to create another source package, bnd2, and to switch all
r-deps to this new version. I suggest to use the current available 2.1.0
in experimental as a starting point for this new package and I am
looking for a sponsor to upload it.

BND has 29 reverse-dependencies. Most of the build failures are trivial
to fix (adjusting paths and using double hyphens for parameters when BND
is used as a command line tool). However there are also packages that
use the bnd Ant plugin and there seems to be an upstream bug in version
2.1.0 which prevents packages from building correctly.

I have documented everything here:

https://wiki.debian.org/Java/BND2Transition

Regards,

Markus

[toc] | [next] | [standalone]

#8085

Le 06/06/2015 14:44, Markus Koschany a écrit :

> I propose to create another source package, bnd2, and to switch all
> r-deps to this new version.

I'd prefer creating a bnd1 or bnd-1.5 package instead, this avoids
having a bnd2 package in the future with a version 3.x. Several packages
like libasm4-java are in this situation and I find this confusing.

> BND has 29 reverse-dependencies. Most of the build failures are trivial
> to fix (adjusting paths and using double hyphens for parameters when BND
> is used as a command line tool).

I've also seen a flood of ArrayOutOfBoundExceptions related to bnd when
building groovy2, but this didn't prevent the package from building.

Emmanuel Bourg


-- 
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: https://lists.debian.org/557967E8.5070006@apache.org

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

#8096

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

On 16.06.2015 18:37, Emmanuel Bourg wrote:
> Le 16/06/2015 00:16, Emmanuel Bourg a écrit :
> 
>> Ok I'll upload it. However I'll copy the bnd repository instead to keep
>> the packaging history.
> 
> I uploaded the bnd1.50 package, it installs only versioned jar files
> (there is no Maven artifact with a 'debian' or '1.x' version, and the
> jar files in /usr/share/java are suffixed with the version 1.50.0). The
> command line tool is invoked with 'bnd-1.50'.

Thanks for the upload. However I feel that this is another "double work"
situation again. (you probably remember the javahelper case). In my
opinion we should have continued to work on bnd1. I am always open for
improvement suggestions and of course I would have fixed all remaining
issues myself. I have put some thought in bnd1, for example my package
was co-installable whereas bnd-1.50 breaks/replaces bnd <= 2 now. I
don't expect any fatal problems with this decision but this was also
true for bnd1. I also think that we don't really need the packaging
history because it is clear to everyone that the bnd repository contains
all historical information. I would treat bnd1/bnd1.50 simply as a new
package with a clean Git history whose sole goal is to simplify the
transition to bnd2 and then we should get rid of it as soon as possible.
There is no need for fancy Git magic.


> I noticed an issue with the Git repository of the bnd package, the
> upstream version 1.50.0 has been imported on the top of the version
> 2.1.0. On the upstream branch, the files for the version 2.1.0 come
> before the files for the version 1.50.0, and on the master branch the
> changes from the experimental 2.1.0 branch have been merged and then
> replaced with the changes for bnd/1.50.0-9.
> 
> I suggest to clean this by:
> 1. reverting the master branch before the merge commit of the
> experimental branch, and reapplying the changes from bnd/1.50.0-9
> 2. rebasing the experimental branch and remove the merge commit from the
> upstream branch
> 3. removing the upstream imports on the upstream branch for both versions
> 4. merging the experimental branch on the master branch
> 
> This will leave an empty upstream branch, and a master branch ready for
> bnd 2.1.0. The next person working on the package will just have to
> reimport the upstream tarball (that may be a more recent version too).


The issue with bnd's upstream branch was that someone forgot to push the
old 1.50 upstream sources when bnd 1.50 was released. Miguel was the
first one who created an initial upstream branch for bnd and pushed the
2.1.0 sources. I don't perceive the current situation as an issue
because Git master reflects the current state of affairs in unstable and
you still can work with bnd 2.1.0 on the experimental branch. So I am
confident everything will be resolved when we eventually upload 2.1.0-2
to unstable and re-import everything with gbp import-dsc on Git master.

Regards,

Markus

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

#8097

Le 16/06/2015 20:37, Markus Koschany a écrit :

> Thanks for the upload. However I feel that this is another "double work"
> situation again. (you probably remember the javahelper case). In my
> opinion we should have continued to work on bnd1. I am always open for
> improvement suggestions and of course I would have fixed all remaining
> issues myself.

Well, I was concerned about the missing history, but as you said it
wasn't absolutely necessary. I didn't want to bother you with this
aspect and made the changes myself. I used your package as a guide
though, so that wasn't really a double work.


I have put some thought in bnd1, for example my package
> was co-installable whereas bnd-1.50 breaks/replaces bnd <= 2 now. I
> don't expect any fatal problems with this decision but this was also
> true for bnd1.

I don't mind changing this once the package is in unstable. Note that
bnd1 wasn't co-installable either, the Maven artifacts in
/usr/share/maven-repo and the versioned jars in /usr/share/java were
conflicting. piuparts would have bitten us quickly with a RC bug against
both packages.


I also think that we don't really need the packaging
> history because it is clear to everyone that the bnd repository contains
> all historical information. I would treat bnd1/bnd1.50 simply as a new
> package with a clean Git history whose sole goal is to simplify the
> transition to bnd2 and then we should get rid of it as soon as possible.
> There is no need for fancy Git magic.

I'm just prudent, sometimes temporary things last much longer than
expected. If the 1.50 package was to remain in Stretch I'd feel better
if it had a full and self contained history.


> The issue with bnd's upstream branch was that someone forgot to push the
> old 1.50 upstream sources when bnd 1.50 was released. Miguel was the
> first one who created an initial upstream branch for bnd and pushed the
> 2.1.0 sources. I don't perceive the current situation as an issue
> because Git master reflects the current state of affairs in unstable and
> you still can work with bnd 2.1.0 on the experimental branch. So I am
> confident everything will be resolved when we eventually upload 2.1.0-2
> to unstable and re-import everything with gbp import-dsc on Git master.

The messy history on the master branch is bothering though :/ I'm not
blaming anyone, I understand well it was the result of a benign gbp
misuse. Git makes this easily fixable and I'm willing to do the work
necessary to restore a chronological history. But before proceeding I'd
like to ensure Miguel and you do not have pending changes, since the
rebasing would prevent you from pushing them.

Emmanuel Bourg


-- 
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: https://lists.debian.org/5580962B.1010300@apache.org

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

#8098

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

Am 16.06.2015 um 23:33 schrieb Emmanuel Bourg:
> Le 16/06/2015 20:37, Markus Koschany a écrit :
> 
>> Thanks for the upload. However I feel that this is another "double work"
>> situation again. (you probably remember the javahelper case). In my
>> opinion we should have continued to work on bnd1. I am always open for
>> improvement suggestions and of course I would have fixed all remaining
>> issues myself.

Thanks btw for fixing jsch-agent-proxy so quickly.

>
> Well, I was concerned about the missing history, but as you said it
> wasn't absolutely necessary. I didn't want to bother you with this
> aspect and made the changes myself. I used your package as a guide
> though, so that wasn't really a double work.

Ok, I'm glad that you don't perceive it as double work and I have always
appreciate it that members of this team fix minor issues themselves.

> I have put some thought in bnd1, for example my package
>> was co-installable whereas bnd-1.50 breaks/replaces bnd <= 2 now. I
>> don't expect any fatal problems with this decision but this was also
>> true for bnd1.
> 
> I don't mind changing this once the package is in unstable. Note that
> bnd1 wasn't co-installable either, the Maven artifacts in
> /usr/share/maven-repo and the versioned jars in /usr/share/java were
> conflicting. piuparts would have bitten us quickly with a RC bug against
> both packages.

I should have been more precise. My intention was that bnd1 and the
current bnd package in experimental were co-installable. That's why I
changed the symlinks in /usr/share/java. The plan was to move all
packages, which would be broken by an upload of bnd 2.1.0 to unstable,
to the new transitional package bnd1. After that we could upload bnd
2.1.0 from experimental and all remaining r-deps to unstable. I never
envisioned that it should be possible to install bnd with version 1.50
and bnd1 with version 1.50.

> I also think that we don't really need the packaging
>> history because it is clear to everyone that the bnd repository contains
>> all historical information. I would treat bnd1/bnd1.50 simply as a new
>> package with a clean Git history whose sole goal is to simplify the
>> transition to bnd2 and then we should get rid of it as soon as possible.
>> There is no need for fancy Git magic.
> 
> I'm just prudent, sometimes temporary things last much longer than
> expected. If the 1.50 package was to remain in Stretch I'd feel better
> if it had a full and self contained history.

I understand where this assessment comes from. However I believe the
current bnd repository provides all necessary information. I'm just
pragmatical. I'm not very much interested in bnd but I want the
transition to be a success because it affects so many different
packages. My personal goal is to remove the transitional package bnd1.50
before the next freeze. In general I believe we should be more
aggressive with transitions. Especially packages with low popcon values,
"one-time-fire-and-forget uploads", everything that is not very
important and fails to build with recent versions should be removed from
Debian. We should be more stringent in those cases and avoid supporting
multiple versions of the same package.

>> The issue with bnd's upstream branch was that someone forgot to push the
>> old 1.50 upstream sources when bnd 1.50 was released. Miguel was the
>> first one who created an initial upstream branch for bnd and pushed the
>> 2.1.0 sources. I don't perceive the current situation as an issue
>> because Git master reflects the current state of affairs in unstable and
>> you still can work with bnd 2.1.0 on the experimental branch. So I am
>> confident everything will be resolved when we eventually upload 2.1.0-2
>> to unstable and re-import everything with gbp import-dsc on Git master.
> 
> The messy history on the master branch is bothering though :/ I'm not
> blaming anyone, I understand well it was the result of a benign gbp
> misuse. Git makes this easily fixable and I'm willing to do the work
> necessary to restore a chronological history. But before proceeding I'd
> like to ensure Miguel and you do not have pending changes, since the
> rebasing would prevent you from pushing them.

Ok, this is something that doesn't bother me very much because I think
it will be fixed with the upload of bnd 2.1.0 to unstable. I don't have
anything else to commit, from my side, please go ahead.

Regards,

Markus

[toc] | [prev] | [standalone]

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

csiph-web