Re: RFS: mobile-broadband-provider-info (updated package)
On 11/24/11, Bhavani Shankar R <bhavi@ubuntu.com> wrote:
> On Thu, Nov 24, 2011 at 9:06 PM, Joseph R. Justice <jayarejay@gmail.com> wrote:
>> On 11/23/11, Paul Wise <pabs@debian.org> wrote:
>>> On Sun, Nov 13, 2011 at 9:55 PM, Bhavani Shankar R wrote:
>>>> Regarding watch file I'm a bit skeptical as its a package which has
>>>> regular commits upstream and requires frequent updation of the package
>>>> in the archives I think personally and using the ftp site for the
>>>> tarball location in watch file could lead to confusions with the
>>>> versions in the archive. And if the watch file is removed lintian
>>>> throws up error. So Antii (marked in CC) can pitch in I guess.
>>>
>>> This is why I think packaging it at all is possibly a bad idea since
>>> people running Debian stable/oldstable will always have old
>>> information. It would be better if the software that uses it were to
>>> be responsible for downloading it periodically.
>>
>> Wouldn't this combination of factoids [(1) that the package has
>> regular commits upstream of important data contained within the
>> package, (2) that the package therefore needs to be frequently updated
>> to get the new data from upstream incorporated into the package, and
>> (3) that these updates need to be made available to people running
>> Debian stable and oldstable without requiring those people to install
>> a version of this package from testing or unstable] therefore suggest
>> that this package is a candidate for debian-volatile (or whatever that
>> is called these days)? I've been subscribing to the applicable Debian
>> announcement mailing list (debian-volatile-announce@lists.d.o) for a
>> little while now, and I see mention of updates to tzdata and clamav.
>>
>> Looking at
>> http://lists.debian.org/debian-volatile-announce/2011/msg00000.html
>> , I guess it's now called squeeze-updates, not debian-volatile.
>> However, the point still stands: "This suite will contain updates that
>> satisfy one of the following criteria: [...] * The package in question
>> is a data package and the data must be updated in a timely manner
>> (e.g. tzdata)."
>
> I was thinking of uploading regular stable release updates both in
> debian and ubuntu. I'll work on this regard coming weekend. Thanks for
> all inputs and support.
Cool. I don't know the process for getting a package qualified to be
considered under the squeeze-updates policy, but that sounds like what
you (and/or the DD who sponsors your uploads of this package) want to
look into, at least down the road.
>> As for if there should be a watch file, or what the watch file should
>> be if there should be one at all, that I do not know. (Is there a
>> facility / capability yet for watching for changes to a git / bzr / hg
>> / svn / cvs / etc archive, and should that facility be used instead
>> for this package instead of watching a (relatively) static tarball
>> file if the facility is available for use?)
>
> Yes the package does have a git handle:
>
> http://git.gnome.org/browse/mobile-broadband-provider-info/
>
> but there is nothing as such as a static tarball on the site. Need
> more clarity on this.
Well, I'm not involved in packaging for Debian at all, just standing
on the sidelines, so I could be All Wrong about the following. But...
I have the impression that the watch files being talked about
elsewhere in this discussion _typically_ refer to a distinct file or
files of some sort, which can be obtained via anonymous ftp / http /
etc, and which have a distinct version of some sort, be it something
embedded in the file name, or a file time stamp, or whatever. And,
watching that file, changes to its file name, changes to its time
stamp, etc is what's used to determine if a Debian package is
"up-to-date" in terms of its version with respect to the version of
the original source the Debian package is derived from.
If what you are packaging here does not have a distinct file of some
sort that can be used to determine the version of the original source,
but a worthwhile version of some sort can be derived from the source
version's Git handle, and if that Git handle can be used by the Debian
watch file mechanisms to automatically determine when the Debian
package's version is out of date with respect to the original source
file, then it seems to me that this is what should be done. Now, _if_
one can do this, and if how _how_ one does this, I do not know. But,
that seems to be the question that needs to be answered.
Thanks for your time. Hope this is of some use, interest.
Joseph
Reply to: