Hi Sandro, Would you like a patch for current_version-new_revision or for new_upstream_version-1? I assumed the latter, and send two patches also assuming that you'd squash them. Of course I'd be happy to squash them myself and rewrite the messages. Whatever you prefer :-)
Hi Andreas, On Wed, Feb 07, 2018 at 12:50:05AM +0100, Andreas Beckmann wrote: > On 2018-02-06 23:01, Nicholas D Steeves wrote: > > On Tue, Feb 06, 2018 at 04:02:07PM -0500, Sandro Tosi wrote: > >> patch is welcome, NMU is not; feel free to upload the patch to this bug > >> and i'll take care of the upload. thanks for working on this Debian bug > > > > That's fair. The main thing I'd like to avoid is the autoremoval of > > rdepending packages ;-) > > You already reset the timer by keeping the discussion in this bug alive ;-) That's a relief! > > I pushed to the following remote and have also > > attached the patches (see commit messages for more info): > > https://salsa.debian.org/sten-guest/python-regex.git > > Assuming the next upload will be versioned 0.1.20171212-2, the version > in the .maintscript files needs to be 0.1.20171212-2~, i.e. you want > "<version-that-introduced-the-correct-dmh-call>"+"~". > That version will also be OK if a new upstream release comes with the > fix, but not for a NMU (that would be versioned 0.1.20171212-1.1 and you > would need to use 0.1.20171212-1.1~ in that case). Touché. I originally tested new upstream version, then reworked it for a minimal NMU, then reworked the commits into what I hoped would potentially be useful to someone who happened to wonder how to fix a similar bug. > You should squash the two patches, the separation just causes > confusion. I'll do this (if necessary) as soon as I hear back from Sandro about his preference. Ah, yes, and now I see how it would have been best to use 0.1.20171212-2~ in the first patch. > There is no need to bump the version in the .maintscript files for > further uploads to buster (unless you need more bugfixes to the d-m-h > calls) (or unless you are uploading new upstream releases to stretch). > There are only two cases while upgrading: upgrading from a version > without the fix (e.g. stretch or 0.1.20171212-1) or a version with the > fix (in that case the migration can be skipped) Thank you for clearing this up, I might be inductively challenged haha! Might you be willing to add something to this effect to dpkg-maintscript-helper(1)? > regarding the commit message: > > >Maintscripts had: > > symlink_to_dir pathname new-target > > There is no such thing as a "new-target" for symlink_to_dir. > I think the maintscripts had "symlink_to_dir pathname current-package". Yes d-m-h(1) has symlink_to_dir /path/name old-target [prior-version [package]] It took longer than I'd like to admit to realise that symlink_to_dir functions like this. eg, for /path/name cd /path ln -s name symlink-name (aka: new-target) corresponds to dir_to_symlink /path/name symlink-name which is reversed with symlink_to_dir /path/name symlink-name (aka: old-target) | where this is not the new_dir_name <-| For some reason I kept seeing symlink_to_dir /existing/symlink-name new_dir_name > PS: I would likely have sponsored a delayed NMU, after several rounds of > revision ;-) Thank you for your support :-) On the topic of rounds of revision, because a package-dbg depends on package ${binary:Version}, should all package-dbgs do this: dir_to_symlink /path/package-dbg package ? similarly to how automatic -dbgsym packages are handled? If so, I think my patch can be improved by adding this operation to each of the -dbg.maintscripts. Regards, Nicholas
signature.asc
Description: PGP signature
