I'm try to put together a package for a big, complex application. One of
its dependencies isn't in Debian yet. What do I do?

- package up the dependency and somehow get both packages sponsored at the
same time (how?);
- package up the dependency and get it sponsored first... meaning that I'll
be trying to get a library added which has no users.

Neither option seems great, TBH. What's the recommended thing to do here?

Both the application and the library are written in Java, FWIW.

Thanks!

<div dir="ltr"><div>I&#39;m try to put together a package for a big, complex application. One of its dependencies isn&#39;t in Debian yet. What do I do?</div><div><br></div><div>- package up the dependency and somehow get both packages sponsored at the
same time (how?);</div><div>- package up the dependency and get it sponsored first... meaning that I&#39;ll be trying to get a library added which has no users.</div><div><br></div><div>Neither option seems great, TBH. What&#39;s the recommended thing to
do here?</div><div><br></div><div>Both the application and the library are written in Java, FWIW.</div><div><br></div><div>Thanks!</div><div><br></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 2024-05-24 at 16:39 +0200, David Given wrote:

I'm try to put together a package for a big, complex application. One of its dependencies isn't in Debian yet. What do I do?

- package up the dependency and somehow get both packages sponsored at the same time (how?);
- package up the dependency and get it sponsored first... meaning that I'll be trying to get a library added which has no users.

Neither option seems great, TBH. What's the recommended thing to do here?

Both the application and the library are written in Java, FWIW.

Thanks!

Hi David,

Personally, I would go with the first option and package both, whip
them into shape and then submit to mentors together.

If you require help along the way, this list and its subscriber will
help you where they can. For people to better help it would help if the
package and library are in a public git - Would be good if that was
Debian's salsa[1].

[1] https://salsa.debian.org/

Regards

Phil

--

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

-----BEGIN PGP SIGNATURE-----

iQJOBAABCgA4FiEEcKCsRax3nv6E9jrtckqptS8CTIsFAmZQr+AaHHBoaWxpcC53 eWV0dEBrYXRoZW5hcy5vcmcACgkQckqptS8CTIvSsw//UHYwSa1uR2QmaD6sQbYT 8Z+AXdJrG5OOv6POR66zVbuqW6Jj60NHsTF4kaVCdps/NCFD7+KPyJIVhqOTLaUj jE27Rl3lLqjoVAuBZ0vzvLbyl7oOyHU4F92FfdP4ygIbyaa6CBrI5TGUpVXnxuo0 nqdwB9hxNUFcJSzr/0uO38rSRliQfwmpok4piA1jquaptHEQNYn+Rdc7z0fZ5r7a tTO8dn5kdv2YMKzrMtKROQVO2SMlNudU4NXL/dqtQpFlYJwFkPz5w8a1E+BGlhZg k8RryDSqijld5TFZjbwN4vKy1of6JsxJhItleQoK/h2Ec5/2/+79W05RQFVC65Ql bIFY82Njf0rd6h/K8cpyHNZv7X/ObCgeWElHzNiVcxJLb96ef/PlhAVCFifZD+rC gX4LkxunxpXHWmyK9yFN1iYG3vhrRH2srsEfn2HNGZu6VP56CzGlMVYz3gUFkKEM FOKld6DXcwk9t4Z2elkXkP8F9WDhqipi9DBe66FVV0tq0NyYd7B7fSA3+rwr5yfD IiR43bQwLkKThz71RVlopY63DZXWn5YsVuwemj02UKMOUZUtGvtsRjeVMyJ4WlNJ yi2yLwArwq/4i1qZobFQ1LPc9DB4Kk6PmoUnB71DfJ5gMAWavVI28xv/mluEI4tO 4QLU67m/RpPx3MMechpZOzc=
=UIrv
-----END PGP SIGNATU

Hi David,

Le ven. 24 mai 2024 à 17:06, David Given <[email protected]> a écrit :

I'm try to put together a package for a big, complex application. One of
its dependencies isn't in Debian yet. What do I do?

- package up the dependency and somehow get both packages sponsored at the same time (how?);
- package up the dependency and get it sponsored first... meaning that
I'll be trying to get a library added which has no users.

Neither option seems great, TBH. What's the recommended thing to do here?

There is a third option: you can bundle the dependency.
It is especially appropriate when it is from the same upstream authors,
when they chose to split their software into parts that fit together,
but that are not actually used elsewhere.
Also, it makes sense when the dependency is a non-released obscure library
that won't ever be used by some other package.
It is not appropriate if that dependency is a mainstream java library that
just happens to be missing from debian.
In that case, options 1/2 are better.
Check Java Team policy, they might have some doc on that matter.
The tools to do that are uscan (check its man page), debian/copyright,
multiple upstream tarballs, components, and you can find plenty of examples from sources.debian.net.

<div dir="ltr"><div>Hi David,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 24 mai 2024 à 17:06, David Given &lt;<a href="mailto:[email protected]">[email protected]</a>&gt; a écrit :<br></div><blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I&#39;m try to put together a package for a big, complex application. One of its dependencies isn&#39;t in Debian yet. What do I do?</div><div><

</div><div>- package up the dependency and somehow get both packages sponsored at the same time (how?);</div><div>- package up the dependency and get it sponsored first... meaning that I&#39;ll be trying to get a library added which has no users.</div>

<div><br></div><div>Neither option seems great, TBH. What&#39;s the recommended thing to do here?</div></div></blockquote><div><br></div><div>There is a third option: you can bundle the dependency.</div><div>It is especially appropriate when it is from
the same upstream authors, when they chose to split their software into parts that fit together,</div><div>but that are not actually used elsewhere.</div><div>Also, it makes sense when the dependency is a non-released obscure library that won&#39;t ever
be used by some other package.</div><div>It is not appropriate if that dependency is a mainstream java library that just happens to be missing from debian.</div><div>In that case, options 1/2 are better.</div><div>Check Java Team policy, they might have
some doc on that matter.</div><div>The tools to do that are uscan (check its man page), debian/copyright, multiple upstream tarballs, components, and you can find plenty of examples from <a href="http://sources.debian.net">sources.debian.net</a>.</div><

<br></div><div><br></div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Unfortunately they're all external libraries. Right now I'm just trying to
make it build (it uses a new version of gradle...) and am making a list of
the libraries one at a time as I find them. Nothing's particularly complex; examples are Phidias (https://github.com/rotty3000/phidias) and jungrapht ( https://github.com/tomnelson/jungrapht-visualization), but there's more.

AFAICT packaging a Maven Java-only library is, or at least should be,
almost trivial...


On Fri, 24 May 2024 at 18:08, Jérémy Lal <[email protected]> wrote:

Hi David,

Le ven. 24 mai 2024 à 17:06, David Given <[email protected]> a écrit :

I'm try to put together a package for a big, complex application. One of
its dependencies isn't in Debian yet. What do I do?

- package up the dependency and somehow get both packages sponsored at
the same time (how?);
- package up the dependency and get it sponsored first... meaning that
I'll be trying to get a library added which has no users.

Neither option seems great, TBH. What's the recommended thing to do here?

There is a third option: you can bundle the dependency.
It is especially appropriate when it is from the same upstream authors,
when they chose to split their software into parts that fit together,
but that are not actually used elsewhere.
Also, it makes sense when the dependency is a non-released obscure library that won't ever be used by some other package.
It is not appropriate if that dependency is a mainstream java library that just happens to be missing from debian.
In that case, options 1/2 are better.
Check Java Team policy, they might have some doc on that matter.
The tools to do that are uscan (check its man page), debian/copyright, multiple upstream tarballs, components, and you can find plenty of examples from sources.debian.net.

<div dir="ltr"><div>Unfortunately they&#39;re all external libraries. Right now I&#39;m just trying to make it build (it uses a new version of gradle...) and am making a list of the libraries one at a time as I find them. Nothing&#39;s particularly
complex; examples are Phidias (<a href="https://github.com/rotty3000/phidias">https://github.com/rotty3000/phidias</a>) and jungrapht (<a href="https://github.com/tomnelson/jungrapht-visualization">https://github.com/tomnelson/jungrapht-visualization</a>)
, but there&#39;s more.</div><div><br></div><div>AFAICT packaging a Maven Java-only library is, or at least should be, almost trivial...<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 24 May 2024 at
18:08, Jérémy Lal &lt;<a href="mailto:[email protected]">[email protected]</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi David,</

<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 24 mai 2024 à 17:06, David Given &lt;<a href="mailto:[email protected]" target="_blank">[email protected]</a>&gt; a écrit :<br></div><blockquote class="gmail_quote" style="margin:

0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I&#39;m try to put together a package for a big, complex application. One of its dependencies isn&#39;t in Debian yet. What do I do?</div><div><br></div><div>-
package up the dependency and somehow get both packages sponsored at the same time (how?);</div><div>- package up the dependency and get it sponsored first... meaning that I&#39;ll be trying to get a library added which has no users.</div><div><br></div><

Neither option seems great, TBH. What&#39;s the recommended thing to do here?</div></div></blockquote><div><br></div><div>There is a third option: you can bundle the dependency.</div><div>It is especially appropriate when it is from the same upstream

authors, when they chose to split their software into parts that fit together,</div><div>but that are not actually used elsewhere.</div><div>Also, it makes sense when the dependency is a non-released obscure library that won&#39;t ever be used by some
other package.</div><div>It is not appropriate if that dependency is a mainstream java library that just happens to be missing from debian.</div><div>In that case, options 1/2 are better.</div><div>Check Java Team policy, they might have some doc on that
matter.</div><div>The tools to do that are uscan (check its man page), debian/copyright, multiple upstream tarballs, components, and you can find plenty of examples from <a href="http://sources.debian.net" target="_blank">sources.debian.net</a>.</div><

<br></div><div><br></div></div></div>

</blockquote></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-05-24 16:39 +0200, David Given wrote:

I'm try to put together a package for a big, complex application. One of
its dependencies isn't in Debian yet. What do I do?

Package the dependency first.

- package up the dependency and somehow get both packages sponsored at the same time (how?);
- package up the dependency and get it sponsored first... meaning that I'll be trying to get a library added which has no users.

This is what I do. All packages have no users before they enter the
archive so that's not really a problem. I quite often find that there
in fact other packages using a library in the archive but they've
bundled it (because that's easier and is often what upstream has
done). So a 3rd step is to file patches for those other packages to
use your library. sources.debian.org is a good place to look for such instances.

You can do both at once but I find it easier if the libraries go in first,
then you can be sure everything works without having to have 'special'
build environment with your extra library packages present.

Mostly it depends how fast you want to move. Either is fine.

Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmZSpU4ACgkQ+4YyUahv nkeQTg//Vs1TYHgTqk3dXhvnEyLXS6RCet4LQjsEzQJC2K7FZYoYsHcUEGTdPuET 2p2et1X9icANsO1Z4YazxJoFQ3W1WhixcLgP18asC0s92i5FQufeB8wZ+yi2LFsH oV4RtsTmkZG3iP7n16kEb84nYiDQnowLXJLrc+nnDv7nkQ3w9GnC6snWxZ1sj9/j do1ipzdqxUo/GCjFPyJZKMBvFwn13xcReaM7fkSAvUR5CB59WN2ssYmYH8SMGCGM l8QHdLXGVGz2kI3qCsMBIN5zgzRh8nTf04fRLdp4WlxApLDu0DpQGZUH+CqEZRoI gbpbRecr0YMPcOKgwZTIHveALFXkecU2WVk3yq4RePpLhG7qUpdqurLuw9pL9avi vnNdztVPuhhINobMz1xNIToPfZU/JmN+xawwNQVPaWxPkeoxVEU2RN7hBnXtmaiF Ti3cb7WHD6lJVnG7tFeb97JEJ6avYCF24kb6HNgCmRB9Hbv9XVGXuqEofrFSN6Co 4nVCf1wR358THjJfAv1JG06jmbf5FkAcbSSdEFhTIHAld35aSItFg836T0bD60cQ EYlTFmOc1zHzquE6E+HqY6B8X33bmhodbQL0obKpyuUEXonL+kSTO9Bp1It9gLZe mZwYjCNrj8EoUHCV6KuBLxLo7bKhSKYVRS//kD7E3M5zDVzjxGo=
=3TOq
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 26 May 2024 at 04:58, Wookey <[email protected]> wrote:

On 2024-05-24 16:39 +0200, David Given wrote:

[...]

- package up the dependency and get it sponsored first... meaning that

I'll

be trying to get a library added which has no users.

This is what I do. All packages have no users before they enter the
archive so that's not really a problem.

Cool. I'll continue trying to make it build and come up with a full list of unpackaged dependencies, and report back.

<div dir="ltr"><div dir="ltr">On Sun, 26 May 2024 at 04:58, Wookey &lt;<a href="mailto:[email protected]">[email protected]</a>&gt; wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px
solid rgb(204,204,204);padding-left:1ex">On 2024-05-24 16:39 +0200, David Given wrote:<br></blockquote><div>[...] <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; -
package up the dependency and get it sponsored first... meaning that I&#39;ll<br>
&gt; be trying to get a library added which has no users.<br>

This is what I do. All packages have no users before they enter the<br>
archive so that&#39;s not really a problem.</blockquote><div><br></div><div>Cool. I&#39;ll continue trying to make it build and come up with a full list of unpackaged dependencies, and report back.<br></div><br></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Wookey <[email protected]> writes:

On 2024-05-24 16:39 +0200, David Given wrote:

I'm try to put together a package for a big, complex application. One of
its dependencies isn't in Debian yet. What do I do?

Package the dependency first.

- package up the dependency and somehow get both packages sponsored at the >> same time (how?);
- package up the dependency and get it sponsored first... meaning that I'll >> be trying to get a library added which has no users.

This is what I do. All packages have no users before they enter the
archive so that's not really a problem. I quite often find that there
in fact other packages using a library in the archive but they've
bundled it (because that's easier and is often what upstream has
done). So a 3rd step is to file patches for those other packages to
use your library. sources.debian.org is a good place to look for such instances.

You can do both at once but I find it easier if the libraries go in first, then you can be sure everything works without having to have 'special'
build environment with your extra library packages present.

Mostly it depends how fast you want to move. Either is fine.

Libs first for me too. Also, it's worth filing an ITP (intent to
package) for the dependency you want to start with, file RFP (request
for packaging) for the ones you wouldn't mind someone else solving while
you work on your initial ITP. You can also file an ITP for the eventual consumer of these dependencies.

Why? So someone doesn't swoop in and package and upload the whole thing
while you're still working on it. It's not a nice feeling.

Having a bug trail also makes it easier for someone to pick up where you
left off if you have to step away from the project for any reason. It's important to you, so it's worth doing, so someone else almost certainly
feels the same way!

Take care,
Nicholas

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmZ8xlgQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYfU6EACpmFFcpsq7WBd9inORKAQcJayS4Yj6Hm+q 9fQ1SAvv3UlzGnthiIJC/5v9tv4A/eh1iMSNIr8aw0LPgne+bLUIcfteyBIyKTmt HN3Ydxl9SfqV2jn96+ufmDvZAkzz5QRqd16vWK+luo3AyR4MdDIRrWSpupuz0iDx 2Rl8ZHkIE+L83j5Yc/StKdy+FE6Myd6SJk/d4nE++9H6Ihs0T+278tNx/1KdjS2a zKSFnsOe37W5VF5F/uKvJSW289JyzJsmrgBq6AHg11hDDZgECJKXvEs8cDfMb00J HQnmkepVtH0CM9vCR/O1/KdzC6Cbd7JLjlsiamtUHcjuf+qYs+mQFe3kokRWee9x Q9H4odYJo+q2Jc88wESKOioUi0jH4n9zqfITOARTw5F4V8WqVRUKgu9/tivExwEH bpWTF7FVZPg2y3+pCZsJ/o7f0XUo3NU2M3E3A5TyZQ7VKwbT++B8aDBwad6S3NzG sWFvzvPn0j4+wSaS0p56/e2HmYdbupF94TFk6fNXYYVLPrMk12RoOIfIvBCxXODk cF+1TKO9UQvq4I6PuIRoJi7kRhNa/hpY6I0+EpxQb0ZOwhfEEa6Q7FjnHGUqWCDi AKoNIxoD14kFFoqk00y0PVaJE8p7K3nTZzGg+OuTQC/2cEPBwY2wycIqRbp2EV72
OLB3qU+giw==
=PCQq
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)