Bug#773378: RFS: ledgersmb/1.3.46-1
Hi Robert,
On Sat, Jan 3, 2015 at 8:26 AM, Robert J. Clay <rjclay@gmail.com> wrote:
> Hi Vincent!
>
> On Fri, Jan 2, 2015 at 6:18 AM, Vincent Cheng <vcheng@debian.org> wrote:
>> Control: tag -1 moreinfo
>>
>> Hi Robert,
>>
>> On Wed, Dec 17, 2014 at 8:54 AM, Robert James Clay <jame@rocasa.us> wrote:
>>> Package: sponsorship-requests
>>> Severity: normal
>>>
>>> Dear mentors,
>>>
>>> I am looking for a sponsor for my package "ledgersmb"
>>>
>>> * Package name : ledgersmb
>>> Version : 1.3.46-1
>>> Upstream Author : Chris Travers <chris@metatrontech.com>
>>> * URL : http://www.ledgersmb.org
>>> * License : GPL-2+
>>> Section : web
>>>
>>> It builds those binary packages:
>>>
>>> ledgersmb - financial accounting and ERP program
>>>
>
>> Just a few small questions/comments from skimming through the debdiff:
>>
>> - You added a small dpkg-maintscript-helper snippet to
>> debian/ledgersmb.postrm, specifically checking if dpkg is new enough
>> to support mv_conffile before using it; what happens if dpkg isn't
>> sufficiently new enough to support that / is that something that
>> should just fail?
>> You can simply add a Pre-Depends:
>> ${misc:Pre-Depends} (which will add a pre-dependency on the
>> appropriate version of dpkg)
>
> That would do that simply because that form of it (mv_conffile) is
> used in the mantainer scripts?
Yes.
>> if you want to use
>> dpkg-maintscript-helper and not have to worry about whether dpkg is
>> new enough (and avoid that "if dpkg-maintscript-helper supports
>> mv_conffile" logic).
>
> That version doesn't quite go back far enough for where I may want to
> support the package. Although it's getting less likely to be an issue
> over time. I'll admit I haven't needed to help with support on
> squeeze or lucid recently; are you thinking that I'm worrying too
> much about a situation that isn't very likely and that would need to
> be supported differently in any case? (For instance, a separate
> backport for it, if necessary.)
I suggest one of three different options (preferably options 2 or 3,
whichever is most appropriate):
1) check if dpkg-maintscript-helper supports mv_conffile and then use
that, otherwise fallback to handwritten logic to rename the conffile
(see [1], or look at how dpkg-maintscript-helper itself is
implemented)
2) pre-depend on a sufficiently recent version of dpkg such that
mv_conffile is always known to be supported
3) don't rename the conffile at all (if it's not necessary)
My concern is that what you're currently doing seems to be a mix of
options 1 and 3, which is possibly worse than any of them, since the
outcome of running your maintainer scripts will differ depending on
what version of dpkg the user already has installed. You either always
want the conffile to be renamed, or you never want the conffile
renamed; I can't think of a valid scenario where you want to rename a
conffile if and only if dpkg supports renaming that conffile.
>> - Why bump the version number in debian/NEWS when there isn't a new
>> entry, and nothing else in the file has changed aside from the
>> timestamp? That seems likely to just annoy apt-listchanges users.
>
> To ensure that it is taken as being current and will be seen again
> as necessary. (I've corresponded with people who didn't look at it
> until I pointed it out that the info was there.)
That seems like something that should go in a readme file, or a
low-priority debconf notice at most. debian/NEWS is essentially meant
to be a more visible user changelog that's used to notify the user of
significant changes [2], not a recurring, identical message that is
displayed every time the user updates this package. That being said,
there's nothing in Policy that prevents maintainers from (ab)using
debian/NEWS for different purposes, so I guess ultimately it's up to
you as maintainer.
Also, AFAIK apt-listchanges isn't installed by default on Debian, so
users aren't guaranteed to see your NEWS entry anyways.
>> Also, note that since Debian is in freeze right now, if you wish to
>> target unstable, any (RC) bugfix uploads that you wish to get into
>> jessie would then have to go through testing-proposed-updates (which
>> the release team apparently really doesn't like). Are you sure you're
>> ok with that?
>
> None of the three bugs I'm seeking to close with this upload are RC,
> so I had not anticipated being able to update the package in jessie in
> any case. (The new package upgrade I'm working on now involves an
> upgrade from v1.3.x to v1.4.x; this upgrade for 1.3.46 is currently
> the last in the 1.3.46 series.)
Ok, sounds fine to me then (please address the
maintscript/conffile-renaming issue though).
Regards,
Vincent
[1] https://wiki.debian.org/DpkgConffileHandling
[2] https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-news-debian
Reply to: