tony mancill <tmanc...@debian.org> writes: >> Felix Natter <fnat...@gmx.net> writes: >> >> Dear Java Team, >> >>> I am looking for someone to review my "insubstantial" package": >>> >>> * Package name : insubstantial (aka flamingo/substance/trident) >>> Version : 7.3+dfsg2-1 >>> Upstream Author : Kirill Grouchnikov >>> * URL : https://github.com/Insubstantial/insubstantial >>> * License : BSD-3-clause >>> Section : java >> >> could you please consider reviewing this package? >> >>> I am not filing an RFS bug yet, because we need to upload fixed r-deps >>> as well (see below), and once the package is ok, I will port the changes >>> as 7.3+dfsg1-1 to alioth. >>> >>> The current (temporary) VCS location is: >>> https://github.com/fnatter/insubstantial-debian >>> >>> (I also uploaded to mentors.d.n. for easy access: >>> http://mentors.debian.net/package/insubstantial) > > Hi Felix,
hello Tony, > I have recently been looking at the package from a copyright > perspective, but just realized that I'm not sure I understand the plan > for the package/transition. It currently builds the following binary > packages, all (or at least most) of which are already in archive owned > by other source packages: > > libflamingo-java > libflamingo-java-doc > liblaf-plugin-java > liblaf-plugin-java-doc > liblaf-widget-java > liblaf-widget-java-doc > substance > substance-doc > substance-flamingo > substance-flamingo-doc > substance-swingx > substance-swingx-doc > libtrident-java > libtrident-java-doc > > First are you confident that we want to use the insubstantial project as > upstream for all of these? (And what makes you confident?) [if your question refers to "why one source package for all":] Since version 7.3, all 7 libraries share the same upstream version, upstream tarball, and project page (https://github.com/Insubstantial/insubstantial). Previously, most/all the 7 libraries had different homepages (underneath java.net, not available any more) and independent tarballs. So to me it seems very natural to use a single source package for all 7. [if your question refers to "why insubstantial at all?"] Insubstantial 7.3 is used by freeplane 1.4, and the other r-deps also work with it (with some rather simple patches I provide), and I think it is _the_ source of flamingo/substance/trident as of today. For instance, if you search for ArtifactId=flamingo on maven.org then only the insubstantial version is returned. > Second, will unsubstantial be able to provide JARs with the right maven > metadata, etc. for other/new r-deps? It seems like we're lumping the > version numbers of all of these JARs into one - 7.3. First question: The current gradle build system does provide binary/source/javadoc jars, but not yet pom.xml's. However, the libs are available on maven.org (http://search.maven.org/#search|ga|1|insubstantial), so there is probably an automated solution for this. I'll have to ask. Otherwise: Can we just use (modified versions of) the pom.xml's from maven.org? 2nd question: I think this is upstream's intention, so why not? > Finally, if we do move forward with this, we'll need to remove the > source packages for all of the above. Agreed, I forgot to list this. > What's the motivation for the big change? As described above, it seems natural and saves a lot of development/maintenance effort. If we split this into 7 source packages, then either we duplicate the source code of 6 other libs, or we have to strip 6 other libraries from the uscan tarball. Also patches to the (gradle) build system will be duplicated across all source packages. Cheers and Best Regards, -- Felix Natter
