-
-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Packaging for Debian, and debian/
#1312
Comments
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 We (@zarkdav) added the Therefore, I think a variant option 3 may be the best way forward here. We would rename The net result would be that this repo would no longer contain a Do you require a new release with a tarball that does not have the |
The changes I propose are in #1313. I have tested this with a locally modified 0.11.0 tarball that does not contain a |
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.
As long as you see fit, this can do.
The way I'm packaging it doesn't require a release tarball, being on the master branch is sufficient. Thanks for being so considerate :> |
Thanks! It should be in Debian fairly soon (depending on FTP masters' workload) :> |
@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 Would you mind renaming it to Added here to avoid opening an issue not quite relevant upstream. |
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. |
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.
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.
Your opinion carries more weight than mine here ;) |
@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 |
@fujiapple852 please see the bug report for more context :| My last email didn't seem to reach your inbox. |
@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! |
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. |
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. |
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. |
Hi, sorry for the delay.
Salvo Tomaselli (the other side of the name conflict) said
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.
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.
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.
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. |
Thank you @nc7s. |
@nc7s I see that it has made it into testing now, that is great! I am able to install and run it from As I understand it FYI I expect to release |
No, people do use testing or even unstable. For those who are familiar, mentioning it's currently only in testing would be enough. |
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:debian/
to a secondary location in source control, and move it "back" in CI. Probably the least intrusive but kinda ugly.Would love to hear your opinions :>
The text was updated successfully, but these errors were encountered: