Re: Version changing while there is an opened RFS
Hello,
You can maybe do something like:
download tarball from last master branch https://github.com/EionRobb/skype4pidgin/tarball/master
(automatic tarball generation)
call it something like
20240123+gitecef199+dfsg-1
20140930+svn665+dfsg-2
$ dpkg --compare-versions 20240123+gitecef199+dfsg-1 gt 20140930+svn665+dfsg-2 && echo true
true
G.
Il martedì 23 gennaio 2024 alle ore 09:40:11 CET, Patrick ZAJDA <patrick@zajda.fr> ha scritto:
Hello,
Le 23/01/2024 à 01:27, Gianfranco Costamagna a écrit :
>
>> I intent to adopt pidgin-skype package.
>> The package version is based on last upstream Git main branch commit, to
>> keep same versioning the package has already.
>>
>> To successfully enable hardening, I created a patch I contributed
>> upstream by opening a pull request.
>> The pull request was merged some hours after.
>>
>> What should I do now?
>> Continue with the same version using the patch?
>> Bump new version and in this case, should I only change the actual
>> version in debian/changelog or create a new version to change upstream
>> version and keep the version the RFS is opened for?
>>
>> Thanks and best regards,
>
> As first answer?
> Please ask upstream to release something new, don't make every distribution rely on git snapshots,
> because it's hard to understand when something is "stable" enough without a tagged release.
> If this isn't possible, either packaging a new snapshot or applying it as patch and bump Debian
> revision from N to N+1 is ok.
> (maybe it depends on the patch size, if small, a patch is ok to avoid import of a new tarball, if the patch
> is huge, maybe the latter is preferred. Also, there might be other commits between the Debian snapshot
> and the patch upstream acceptance, so check all the commits for their stability).
>
> Sorry for not providing a good answer but "it depends" is probably the right one.
>
> G.
Firstly, I would really have preferred to avoid these kind of version :-)
But the latest release was about three years ago, maybe I could ask the
project maintainer to tag a new version... Before the yesterday commit
which applies the patch, previous was on July 10, 2023.
And because actual package version is an SVN snapshot, I don't know how
I could change version chem without using epoch. Woule
yyymmdd+realyversion+dfsg be OK?
But there is still the fact latest version is very old and a lot of
fixes have been applied since.
Anyway, if I read you correctly and because my patch modifies only two
lines with only one useful for the Debian package, maybe it is OK to
wait for a review of the actual package I opened a RFS for.
Thanks and best regards,
--
Patrick ZAJDA
Reply to: