On Fri, May 07, 2021 at 10:40:31AM +0200, Emmanuel Bourg wrote:
> Le 07/05/2021 à 10:12, Matthias Klose a écrit :
>> sure. but maybe remove the "plus" signs from the upstream version, so that the
>> final 1.31.1 version is newer than the current version? or will it be a
>> 1.31.1+dfsg version?
>
> I also agree with Matthias on the version, the '+' could be removed so
> we can upload a clean 1.3.31 version later.
>
> Did you start working on packaging kotlinx coroutines and atomicfu
> separately yet? That will be the next step once kotlin is uploaded.
Hi both, thanks for the reviews.
I disagree on the version numbering. As described in README.source and
the commit messages for the watch file, this is the standardised format
for MUT support in uscan, admittedly more often seen in javascript.
There is an alternative, checksum '1.3.31+~cs1.11.13', but that does not
support uscan --download-current-version which is needed until we can
bump them all to their latest tags.
Relatedly, I'm not convinced by the plan to package them separately, as
the purpose of the components was to break the Build-Depends cycle.
After the initial upload, it makes sense to allow kotlinised gradle into
the cycle so we can drop a lot of custom build patches. However, we
could choose to keep (and CI) debian/bootstrap for the long run,
producing separate binary packages, but not necessarily source.
If you still disagree, then I ask that we not change it until after the
upload, since separate source packages will naturally restore the clean
version numbering as you go. That will also make it easier to handle the
file collisions from shifting those jar's source package.
>> - debian/bootstrap creates a deb, which has the deb itself
>> in the root directory.
Again from the commit messages, this too was deliberate and only
partially lazy to simplify the implementation code:
* default name is debian/tmp.deb, so output into BUILD_DIR to auto name
* because the dir is simultaneously written and read, there's a useless
tiny file embedded into the generated kotlin_*.deb
>> Is there any reason to use debhelper 13? Does it have anything that is relevant
>> for java packages? Just asking because that's usually something which needs to
>> be downgraded for backports.
Are you planning to upload to stretch or ubuntu 18.04? 13 is in
buster-backports and I believe these changes are relevant for java:
v13 This is the recommended mode of operation.
- The third-party gradle build system (from gradle-debian-helper
package) now runs the upstream-provided test suite automatically.
- The dh_missing command will now default to --fail-missing.
- The dh command sequencer will now skip all hook and override targets
for dh_auto_test when DEB_BUILD_OPTIONS lists the relevant nocheck /
nostrip options.
Attachment:
signature.asc
Description: PGP signature