[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS for libimglib2-java and libparsington-java



Am 16.08.2017 um 21:25 schrieb Ghislain Vaillant:
> On 16/08/17 19:47, Markus Koschany wrote:
>> Am 15.08.2017 um 11:18 schrieb Ghislain Vaillant:
>>
>> I never had to use build profiles because for me it was always something
>> related to bootstrapping Debian as a whole. This is actually the first
>> Java package I have seen where someone makes use of the build profile
>> syntax in debian/control.
> 
> So far I have mostly packaged Python libraries, where building the
> documentation often requires pulling quite a few extra dependencies,
> including other -doc packages.
> 
> On the other hand, if all Javadoc packages only require default-jdk-doc
> as b-dep, then the benefits of supporting nodoc would be pretty small.

Sometimes we build-depend on other -doc packages for cross-referencing
other Javadocs but I don't believe the extra dependencies have ever
caused any issues. As mentioned in the recent DebConf thread we plan to
reduce the amount of -doc packages, so it is at least questionable how
relevant nodoc build profiles for Java packages will be in the future.

>> I still believe what you want is support for DEB_BUILD_OPTIONS=nodoc
>> similar to DEB_BUILD_OPTIONS=nocheck. The nodoc option will be supported
>> by maven-debian-helper soon according to one of Emmanuel's last posts on
>> this list. I assume this will simply suppress the Javadoc step and you
>> will end up with an empty doc package which is basically the same as
>> having no documentation at all.
> 
> Indeed, though the extra dependencies for building the docs will be
> pulled, which kind of defeats the purpose IMO.
> 
> Basically, I agree with https://wiki.debian.org/DebianBootstrap, in the
> "Documentation loops" section:
> 
> "Building without docs usually affects the build-dependencies, so it is
> not quite like other DEB_BUILD_OPTIONS, and using DEB_BUILD_PROFILES
> instead now makes more sense."
> 
> and apply the same logic to nocheck too. If I don't intend to build with
> tests enabled, then why pulling the extra dependencies to the build.

The difference between DEB_BUILD_OPTIONS and DEB_BUILD_PROFILES is that
you have to add those nodoc annotations to all debian/control files.
Once DEB_BUILD_OPTIONS=nodoc is supported by maven-debian-helper no
further steps are required. It is unlikely that libimglib2-java or
libparsington-java are affected by bootstrapping issues. If we want to
support bootstrapping we should identify key packages first and then
implement such build profiles in those packages. However at the moment
we simply don't know what Java packages have to implement such build
profiles to break the dependency loop cycle. In my opinion it would be
premature to add those stanzas to all doc packages when nobody is
actively working on this topic.

Not installing extra dependencies is certainly a bonus but the reason
why nocheck and nodoc build options primarily exist is to skip certain
build steps. Skipping OpenJDK tests means hours of time saved but the
installation of extra dependencies is a matter of one or two minutes.

> Again, for Python, support for nocheck can make sense because the Python
> packaging metadata already make the separation between build, install
> and tests requirements. Perhaps it does not make sense for Java?

Nocheck is already supported by all Java packages. You can also use the
maven.test.skip=true option in maven.properties for all Maven based
packages.

>> I don't mind uploading the package as is but wanted to point out that
>> build profiles is probably not what you really want.
> 
> Anyway, if you prefer that I take it out, that's absolutely fine by me.
> 
> The package will be team-maintained, so the content of the packaging
> should be normalized as per the team's habits, I guess.
> 
> Please let me know.

I believe we should keep it simple and try to avoid using build profiles
except someone is really going to work on this stuff and files bug
reports and identifies key packages. If we decide to add build profiles
we should do it in a consistent way though.

I suggest to wait one more day for further feedback. If there are no
objections, please remove the build profiles.

Markus

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: