Packaging for Debian, and `debian/`

[nc7s]

Hi. First of all, thanks for making this wonderful tool!

There's been some progress in packaging trippy in Debian. However, there's also some slight annoyance, specifically with debian/.

You see, Debian packaging is always laid out in the debian/ directory, be it for inclusion in the main Debian archive, or in your own repository, even as a standalone .deb. trippy upstream here currently is the last case, using cargo-deb, which pulls in non-Debian dependencies, and the product obviously can not enter the Debian archive. We, being downstream in Debian thus the first case, inevitably face the conflict between the two. Here are some ways we can make it work:

1. Keep it as is upstream (here), and override in downstream (Debian) to fit the requirements, resolving conflicts as we go. Shortcomings are rather obvious.
2. Keep a canonical packaging upstream. This might have some process complications, as a Debian maintainer might need to pick up the upstream hat. Benefits include unification of packaging and closer connection along the stream.
3. In upstream, move debian/ to a secondary location in source control, and move it "back" in CI. Probably the least intrusive but kinda ugly.
4. Something even better?

Would love to hear your opinions :>

[fujiapple852]

Hi there @nc7s, thanks for taking the time to do this, it would be great to have Trippy packaged in Debian!

Just to check my understanding, I assume your preference is to maintain a debian/ directory in the downstream Debian repository rather than maintain it upstream (i.e. here)?

We (@zarkdav) added the debian/ directory here to allow producing a Ubuntu PPA, in lieu of downstream Debian packaging being available. Also, i'm confident this directory is not needed for the cargo-deb CI step, as that predates the work to support PPA.

Therefore, I think a variant option 3 may be the best way forward here. We would rename debian/ as ppa/ (or similar) and adjust the PPA release script to rename it as debian/ when it is copied into each series during the release. I will need to test that this works, but in principle I can't see any reason why it would not.

The net result would be that this repo would no longer contain a debian/ directory at all, which I assume meets your needs?

Do you require a new release with a tarball that does not have the debian/ directory, or is it sufficient that the change is made on the master branch?

[fujiapple852]

The changes I propose are in https://github.com/fujiapple852/trippy/pull/1313.

I have tested this with a locally modified 0.11.0 tarball that does not contain a debian/ directory and it works (I can build and simulate the upload of the PPA).

[nc7s]

Hi there @nc7s, thanks for taking the time to do this, it would be great to have Trippy packaged in Debian!

Just to check my understanding, I assume your preference is to maintain a debian/ directory in the downstream Debian repository rather than maintain it upstream (i.e. here)?

My preference is to avoid overrides and conflicts downstream, not necessarily the "rather than"; for that we can go option 2. Though it inevitably involves either someone from Debian maintaining it here ("picking up the upstream hat"), or you effectively becoming a Debian maintainer there (picking up the "downstream hat"). Depending on the complexity, it might not be favorable.

Therefore, I think a variant option 3 may be the best way forward here. We would rename debian/ as ppa/ (or similar) and adjust the PPA release script to rename it as debian/ when it is copied into each series during the release. I will need to test that this works, but in principle I can't see any reason why it would not.

The net result would be that this repo would no longer contain a debian/ directory at all, which I assume meets your needs?

As long as you see fit, this can do.

Do you require a new release with a tarball that does not have the debian/ directory, or is it sufficient that the change is made on the master branch?

The way I'm packaging it doesn't require a release tarball, being on the master branch is sufficient. Thanks for being so considerate :>

[fujiapple852]

Thanks @nc7s that all sounds fine.

I’ve just merged #1313 to master so you should be all set!

[nc7s]

Thanks! It should be in Debian fairly soon (depending on FTP masters' workload) :>

[nc7s]

@fujiapple852 It's now in Debian, as can be seen in the repology badge ;) however, there's again a (supposedly) minor annoyance: the executable named trip conflicts with another package, as reported in this bug.

Would you mind renaming it to trippy in Debian? Users could still alias it to trip. But I'll convey your opinion either way. Or if you feel like it, reply to 1082825@bugs.debian.org, vasttrafik-cli@packages.debian.org with your upstream hat on :> (the latter is to keep the other side of the conflict in the loop; arcane, I know, bug it is what it is.)

Added here to avoid opening an issue not quite relevant upstream.

[fujiapple852]

Thanks @nc7s, yes I saw it on sid and tried it out, works great! Thanks again for doing that.

As an aside, I saw you had to make a few small patches, mostly removing or downgrading dependencies which likely can't be avoided, but do let me know if there is anything I can do upstream to avoid the need for any of these in the future.

Regarding the name clash, i'm not keen on the idea of renaming it as it would then be different on debian (and all derivatives) from every other ecosystem that has packaged it so far.

I seem to recall a similar discussion for snap packaging as well, but in the end the maintainers decided the probability of a clash was low given the different nature of the two packages.

Edit: found the discussion, and it is indeed the same package: https://forum.snapcraft.io/t/request-auto-connect-network-observe-for-trippy/31972/2

How are these situations usually handled in Debian? I can see some guidance here about declaring conflicts, would that be the best way forward?

I'm happy to reply to the address above and give my opinion.

[nc7s]

As an aside, I saw you had to make a few small patches, mostly removing or downgrading dependencies which likely can't be avoided, but do let me know if there is anything I can do upstream to avoid the need for any of these in the future.

That's an (unfortunate?) consequence of us lacking the resources to keep everything up to date. Not much to do on the upstream side - these patches are mostly downgrading and disabling dependencies, which you can't change anyway.

I seem to recall a similar discussion for snap packaging as well, but in the end the maintainers decided the probability of a clash was low given the different nature of the two packages.

This is probably the case, though I don't really have an opinion here. vasttrafik-cli has a popcon of 5, trippy currently 10, both relatively low. OTOH, violating the Debian policy would block it from entering testing thus stable, not much I can do about that. Conflicts is a way out, though if we are to err on the "correctness" side, it's possible someone would want to install both.

I'm happy to reply to the address above and give my opinion.

Your opinion carries more weight than mine here ;)

[fujiapple852]

@nc7s I see that the maintainer of the conflicting package has very kindly agreed to rename the binary in a week or so, and so it seems we have a resolution. Given that, I won't reply to the list suggesting using Conflicts as I had planned as that may only cause confusion now.

[nc7s]

@fujiapple852 please see the bug report for more context :| My last email didn't seem to reach your inbox.

[fujiapple852]

@nc7s I did see both your last email and the latest reply. My interpretation is that the issue is now resolved (the conflicting package has now been renamed), do you interpret it differently? I was assuming, therefore, that the blocking bug could/would now be closed.

Also I just wanted to say that you certainly don't owe me any apology, i'm very grateful for your efforts here!

[nc7s]

Looking at the status quo yes, the problem could be considered solved, but my handling of this was much less than ideal. I said sorry to you because this might harm your rep as an upstream.

[c-git]

From my naive point of view, I read the email thread and it seems fine. You did imply that the name change would not be a problem but you didn't claim to have already asked how upstream felt. You only made the claim that upstream is co-operative (which I think is true). In the end I also want to thank you as I had previously looked into getting it packaged for Debian but bounced off the process due to time constraints.

[fujiapple852]

Hi again @nc7s, just checking in on this.

I see the existing release critical bug report is unresolved and there is also a new (non-blocking it would seem?) bug report.

What is the process for resolving the critical issue, is it something we can do or does it have to come from the person who raised the issue (Helmut)?

It looks like the bug may have been created by a automated tool, but seemingly the tool does not close them automatically once the conflict is resolved.

Thanks as ever and do let me know if there is anything needed from me here.

[nc7s]

Hi, sorry for the delay.

I see the existing release critical bug report is unresolved

Salvo Tomaselli (the other side of the name conflict) said

Having been in free sotware circles for a while, I'm honestly not surprised at all.

So I think he's a bit disappointed but didn't really object to your insisting on the name.

Lack of further action on my side was due to other things in life.

What is the process for resolving the critical issue

Bugs (issues but in Debian lingo) of the "critical" severity are still bugs, just close them when they are fixed. There's no special handling required in the bug process.

is it something we can do or does it have to come from the person who raised the issue (Helmut)?

Generally the bug should be closed by either the reporter or the maintainer. I could close it as the maintainer but wanted to word it better as I kinda owe Salvo one on this.

It looks like the bug may have been created by a automated tool, but seemingly the tool does not close them automatically once the conflict is resolved.

Yes. The automated tool is used to discover problems and report them to maintainers, but "once the conflict is resolved" is often a manual decision. In this case, the problem isn't only technical, but also political (in a broader sense), which automated tools don't understand (yet?).

Like said, I'll try to do some wording and close it.

[fujiapple852]

Thank you @nc7s.