Re: Data updates in debian packages
Hi Paul,
On 29.10.2016 03:37, Paul Wise wrote:
> On Fri, Oct 28, 2016 at 6:38 PM, Ole Streicher wrote:
>> We have the problem (I am not sure whether I posted about this already),
>> that the "casacore" package needs additional "casacore-data-XXX"
>> packages, providing the basic data to work with casacore. Some of the
>> data are almost immutable, others (for example leap seconds) are
>> changing every year or so, and others change quite rapidly (high
>> precision ephemides forecasts). They all can be downloaded from some FTP
>> servers.
>
> FYI leap seconds are already packaged multiple times in Debian, so
> please do not add another copy of them.
The package in question (casacore) wants them in a specific format "CASA
table" (which is uniformly used within that package), and dependent
packages access this in that specific format. The only way would be to
create this table from another leap second table (instead of our current
source usno.navy.mil), and to update this every time the original table
is updated (which I would have to learn how to do this).
Probably the canonical source would be:
> tzdata: /usr/share/zoneinfo/leap-seconds.list
however it worries me a bit that leap seconds are not directly mentioned
there. How sure can one be that they will be installed in-time?
>> How should the update service work? Can it just overwrite the existing
>> files? How one should handle if an update (with possibly older data) in
>> installed to not downgrade the data?
>
> Check out pciutils/usbutils and similar.
>
> Essentially:
>
> Make the applications look in /var by default.
>
> Put the packaged data in /usr/share.
>
> Have the postinst symlink from /var to /usr/share when the /var
> location is missing or older than the /usr/share location.
Looks like a plan ;-) I'll start there. What would be the default place?
/var/lib/casacore/data?
> Have an update script that can be run by the sysadmin or from cron
> that downloads the latest version and atomically replaces the data in
> the /var location.
What I would do here is a separate package "casacore-data-autoupdater"
that provides that service for all installed casacore-data-XXX packages.
That package would install itself into /etc/cron.daily and, when called,
check the age of each installed data table and update if necessary.
Having this service centralized would avoid a debconf script for each
package to ask the user several times for if he wants to auto-update
that table.
The name and the description of the package would make it clear that it
will access the data via net.
The update script itself could even be distributed with the casacore
package itself. And for simplicity I would make
casacore-data-autoupdater a binary package within the casacore source
package (since this is the main dependency anyway).
Comments on that? What would be the best dependency specification then?
casacore-data-autoupdater "suggests" casacore-data-XXX and/ore vice-versa?
> Make sure that any security/privacy consequences of the non-apt update
> method are dealt with.
If you have comments on my proposal, please comment.
Best regards
Ole
Reply to: