On 2024-07-15 12 h 00, Chris Knadle wrote:
Hello Daniel and Michel.
Daniel I see that you're a Debian Developer as of this year,
congratulations.
That said, it's unusual as a package maintainer to be /told/ that a
package I maintain is going to be NMUed with a new version that
significantly changes the package, without any serious bug on the
package. There's been no mention of the package's Salsa Git repository
or how that would be reconciled. The rules for Debian that I'm aware of
would preclude doing this without the package maintainer's go-ahead.
Hi,
As stated earlier in this bug, I did this packaging work for my own
evaluation of the new mlmmj upstream and put it on salsa with the hope
it could be useful to somebody. I used the standards and tools I use in
my other packages but I'm not advocating for mlmmj to switch to them.
Daniel contacted me to ask about an upload to experimental and I told
him he could use my packaging work if he wanted to, I assumed he had
some form of understanding with the maintainers.
I've had a very brief look at Michael's package. I don't understand the
new debian/changelog entries, it looks like Git commit numbers have been
included, I've never seen that before in any Debian package and I'm
wondering how that could be useful to any Debian end user. The
debian/changelog entries are not just for developers, Debian end users
use them to know what changes the package has gone through; I think I
would prefer those Git commit comments not be there unless there's good
justification. I don't understand the debian/control file concerning new
build dependencies I don't recognized and that have <!nocheck> entries.
(What is that?) A new salsa-ci.yml file is included which is going to do
-- something -- which hasn't been discussed. The debian/rules have been
converted to automatic 'dh' rules, and there needs to be detailed review
of what the end-effect of changing those rules are compared to the
current package in Debian. Changing the debian/rules is specifically
something not to change without consent from the package maintainer.
The added dependencies have to do with the test suite the new upstream
added. The '<!nockeck>' tag is related to Build Profiles [1] and is used
on some buildds to disable the test suite when building the package.
Please do not upload this package as it is right now, I think the needs
changes before it could be released. This is not a situation where
Michael's Git repo could simply be imported into the Debian MLMMJ Git
repository, because there's several past versions that were never
released to Debian and so don't belong in the Salsa Git repo. I don't
think I know enough Git magic (rebase?) to reconcile all that to make a
clean Salsa Git history of Debian releases.
And if you're not aware, the install instructions for MLMMJ for Exim4
also need updating after changes to Exim4 for disallowing using "tainted
data" and I don't yet know if the new upstream fork has updated those
instructions. That was discussed on the MLMMJ mailing list, which is
still active. Let me know if you are on the mailing list for MLMMJ to
see the discussion of these issues.
I appreciate the work Micheal has done to create a new Debian package of
MLMMJ, it's definitely going to be useful even if it can't be released
directly. At minimum there should be away of 'cherry picking' Git
commits to include in a new MLMMJ Debian release.
Daniel when you have time please let me know your thoughts about all
this. Hopefully we can figure out a way to make this work, because I
could certainly use help.
I still hope this new version of mlmmj can make it in for trixie
whatever the packaging details are and if there is anything I can to do
to help, please reach out to me.
Cheers,
Michael
[1] https://wiki.debian.org/BuildProfileSpec
