[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Data updates in debian packages

On Sat, Oct 29, 2016 at 8:45 PM, Ole Streicher wrote:

> 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).

You can use dpkg triggers to update files in response to packages
updating other files.

> 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?

They are in the tzdata package, you can use Depends to ensure it is installed.

> What would be the default place?
> /var/lib/casacore/data?

Sounds good.

> 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,

Please ensure that all the systems that install this package do not do
the download at the same time, to spread the load out a bit. Check out
these files in the apt package for a good way to do that, which avoids
cron jobs sleeping for ages on systemd-based systems and uses random
sleeps with cron on other systems:


> 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?

casacore-data-autoupdater Enhances: casacore-data-XXX
casacore-data-XXX Recommends: casacore-data-autoupdater

>> 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.

I don't know enough about the formats and the download processes to comment.



Reply to: