transmission-gtk is included in Ubuntu Desktop's default install
(specifically the expanded install option). This means that
transmission-gtk is in Ubuntu main and all its dependencies must be in
Ubuntu main instead of in Ubuntu universe.

libb64 is in Ubuntu universe. After an initial review, I determined
that libb64 does not seem like a good candidate for Ubuntu's Main
Inclusion process [1]. Therefore, I will need to re-vendor libb64
inside the transmission package. If Debian does the same, then it
would be possible for Debian and Ubuntu to share the same packaging,
allowing package improvements to more quickly reach Ubuntu during the
part of Ubuntu's development cycle when automatic sync is enabled.

Specifically:
- libb64 has been unmaintained since 2013
https://sourceforge.net/p/libb64/git/commit_browser
- libb64 has several open bugs, some of which have security implications
https://sourceforge.net/p/libb64/bugs/
- libb64 is missing a pkgconfig file which is a relatively simple
standard way for other software to use libb64
https://launchpad.net/bugs/1534293
- The Debian packaging is not using simple dh rules. The packaging
seems to otherwise be fairly modern but it's more complicated than
typical Debian packages.
https://salsa.debian.org/alteholz/libb64/-/blob/master/debian/rules

Reference
--------------
[1] https://github.com/canonical/ubuntu-mir

Thank you,
Jeremy Bícha

block 1073005 by 1073203
thanks

Hi,

Thanks for raising this to our attention.

[...]

Regarding those valid points, because there is not reason to have the same
source in multiple packages, there are only 2 paths compliant with the Debian
policy:

    1) Fix those points in src:libb64 for transmission and all rdepends
    2) Remove src:libb64 from Debian and then vendor in transmission source

I'll try to move towards 1) and see how it goes. So for now, this is a
wontfix because against DFSG.

Thanks,

Alex

I agree that it would be helpful if many of these issues were fixed
for all users of libb64.

On the other hand, this does not fix the fact that libb64 has been
unmaintained since 2013 and therefore it still wouldn't be a good
candidate to complete Ubuntu's Main Inclusion process even if the
other issues were fixed. Therefore, Ubuntu will need to keep vendoring
libb64 in transmission. I am unaware of any maintained version of
libb64.

I disagree that this violates the Debian Free Software Guidelines
although it does violate what is normally considered "best practice"
in Debian development. However, there are many exceptions to this best
practice in Debian and there is a lot of vendored code. (Even after
your recent work, transmission still has vendored code and that is not
a DFSG violation). Notably, Debian ftpmasters routinely accept new
packages that have vendored code as long as the code is correctly
documented in debian/copyright (which had been done for transmission).
See https://wiki.debian.org/EmbeddedCopies

Thank you,
Jeremy Bícha

Hi,

Debian policy 4.13:

    If the included code is already in the Debian archive in the form of
    a library, the Debian packaging should ensure that binary packages
    reference the libraries already in Debian and the convenience copy
    is not used.

I reckon *should* is not *must*.

I'll seek advice on this.

Thanks,

Alex

Transmission could also switch to openssl's ability to encode/decode base64:
https://github.com/transmission/transmission/discussions/6970

Hi,

I've done it and proposed a pull request.

https://salsa.debian.org/niol/libb64

Thanks,

Alex