My frustration is with packages released with changelog files containing something else than a strict log of release changes. Regardless of tooling!
With "a strict log of release changes" I mean that each section of the logfile summarizes the change between that and the previous section of that file.
Cool stuff, thanks @jonas.smedegaard , @mladen !
Status update:
Confirmed, the network-manager-openvpn 1.8.14-1~pureos1 fixes the issue! Thank you @jonas.smedegaard
If you are interested, then I do have suggestions on how to try keep both qualities small - i.e. semi-automated routines - but they evolve around a core principle of treating the parent source (Debian) as the primary and PureOS getting applied on top.
I'd be more than interested ;)
What i'm after is that the changelog content is not related to how the package is prepared. There's tools to aid certain workflows but for d/changelog itself doesn't know anything about that. (what you describe sounds more like frustration about tool failing).
If you are interested, then I do have suggestions on how to try keep both qualities small - i.e. semi-automated routines - but they evolve around a core principle of treating the parent source (Debian) as the primary and PureOS getting applied on top.
To me, best practice of maintaining a fork prioritizes keeping the difference to a minimum over keeping the maintenance work to a minimum.
NB! I certainly welcome reducing the maintanance burden, I am only talking about the priority of those to qualities: Ideally both should be minimal.
Just to make sure we understand each other: What you call "artifacts" are tangible by-products, right? For comparison, what I call "products" are the packages we ship to our users (not throw-away results of test builds).
I have found that doing git merge <debian tag> on top of an already forked and deviated package leads to a package history which interleaves parent and fork-specific changes, which I have not found a way to automatically produce a (to me) comprehensible changelog from.
See also https://source.puri.sm/-/snippets/1165 which contains above script + my notes on surrounding tasks that I have so far been unable to automate, because I have so far found to it too variable across packages.
I am not fluent in Gitlab, but for the local repo part, I use this:
#!/bin/shI disagree that we should imply that meshed history is a good practice because I think it is incomprehensible to read a meshed history: It lead to my coming up with the "rebasing" strategy b) referenced in this issue report, and later lead me to file T1048 which triggered the creation of this issue report.
We need to find a balance of being comprehensible for you and workable for developers (most of which just merge in the current Debian *git* packaging into the PureOS packaging. Do you have good suggestion here?
Sorry, I have no suggestions on how to frame preparation routines which involves applying Debian changes on top of PureOS changes as "best practice" for maintaining packages forked from Debian.
Any preparation style regardless of non-metadata contents of the changelog file is acceptable (obeys all "must" in Policy).
Except that this is PureOS and not Debian so while it's certainly a good idea to follow Debian policy we shoudn't simply imply that Debian Policy is the only policy and that we need to adhere to all policy points.
True that it might be bad, but until T1047 is solved Debian Policy is what we got for PureOS!
If you are aware of anything broken or incomplete or overzealous for PureOS then please file a separate report for each issue and link them to T1047.
I disagree that we should imply that meshed history is a good practice because I think it is incomprehensible to read a meshed history: It lead to my coming up with the "rebasing" strategy b) referenced in this issue report, and later lead me to file T1048 which triggered the creation of this issue report.
No, but you are debating whether or not meshing changelogs makes them harder to understand.
There are acceptable (obeys all "must" in Policy) and recommended (obeys all "must" and "should" in Policy) and suggested (follows best practices).
When you do a git merge then changelog files are meshed, and when you follow "strategy b)" you don't. That seems rather consequential to me, not orthogonal.
I'm not debating that debian/changelog could be improved.
No, but you are debating whether or not meshing changelogs makes them harder to understand.
I cannot decipher if release 1.14.12-0.1pureos1~amber1 is just "uploaded" and "backported" compared to release 1.14.12-0.1 - i.e. if the patches mentioned for release 1.14.10-0.1~pureos0~amber1 was applied as well or not.
I don't think [having a rule of "changelog should be a log"] is a good idea though since merging changelogs keeps valuable information around [...] and i don't think this would make it any harder for Debian to look at the diffs.
It would need to *become* a policy rule, it isn't one already.
Thanks for the clarification . sorry that I was unclear.
I am talking about the Debian standard for well-structured patches DEP-3 (not DEP-5)
Debian tracker currently link to a single dumb delta between the forked Ubuntu package and its Debian parent (not DEP-3 patches)
my vision is for PureOS to provide DEP-3 patches to ease reuse outside of PureOS - e.g. linked from same place that now links to dumb Ubuntu patches (not that PureOS provide dumb patches like Ubuntu - which I agree is doable regardless of how packages are prepared but is less helpful than DEP-3 patches).
Evangelos wrote:
this was specifically about updating downstream packages (which was the in the initial title btw ;) ).
@evangelos.tzaras: Is the issue you reported here broadly about any and all best any practice(s) in PureOS missing or undocumented?
I am lost - I don't know what we are discussing here.
Possibly my own fault for a) speaking about things I find relevant before the scope of this issue report was properly established, and b) talking about things I explicitly stated previously that I find out of scope (notably requirements as opposed to best practices).
I would love to have https://tracker.debian.org/ also link to PureOS patches - and I see how that is doable by parsing Debian Policy standards-compliant source packages and look for DEP-5 standards-compliant patches. Which standards should I follow to implement such feature for git branches/commits?