Re: What is the best method to update only some binary packages
Hi,
My question is arch:all (not any) ... more specifically,
foo-static_1.0_all.deb is documentation package which does not change
document contents from 1.0 to 1.1 transition.
I know there is a way to do it but I am not sure if it is a good and
valid way. I also was not sure where I have seen it. I think Josip
used to use this trick for translation packages without updates for
something like doc-debian ... wait that is maint-guide .... (I now
maintain). As I see it there are lines in its debian/rules entry which
seems to have meant to forces specific version using dh_gencontrol.
* Is this still useful technique?
* Is this the best method?
* Does anyone know recent ftp mater behavior on such trick?
Let me reply to you as below....
On Thu, Oct 02, 2008 at 04:05:05PM +0100, Neil Williams wrote:
> On Thu, 2008-10-02 at 23:35 +0900, Osamu Aoki wrote:
> > Hi,
> >
> > Suppose source foo_1.0.tar.gz produces:
> > foo-updated_1.0_all.deb
> > foo-static_1.0_all.deb
> >
> > Then with next source foo_1.1.tar.gz with updated contents will produce
> > now with normal build script:
> > foo-updated_1.1_all.deb (updated from foo-updated_1.0_all.deb)
> > foo-static_1.1_all.deb (same as foo-static_1.0_all.deb)
> >
> > Then What is the best way to make update archive to have:
> > foo-updated_1.1_all.deb
> > foo-static_1.0_all.deb
>
> Generally, that is not what you actually want to do.
>
> 1. The source for 1.0 has probably been removed by the archive software
> so distributing 1.0 is now illegal.
Are you sure?
I think it uploaded with foo_1.0_amd64.changes having something like
both foo-updated_1.1_all.deb and foo-static_1.0_all.deb so archive
software will not remove foo-static_1.0_all.deb.
> 2. Keeping the source around is not sensible across 20,000 packages.
Sure but that is not the issue.
> 3. foo-static_1.0_all.deb will not contain the changelog entry for 1.1
> causing differences in the copyright and changelog data across different
> installations
I vaguely remember that uploading set of binary packages such as these
will not move to pool/ since there is already such package. At the same
time, foo_1.0_amd64.changes ensures old foo-static_1.0_all.deb to stay
in archive.
> 4. The dependencies may have changed (at least with respect to Arch:any
> packages that use shlibs) which can cause aggravation with transitions.
> Even with python etc., where packages themselves can be arch:all, having
> old packages around that have not been rebuilt against the latest
> interpreter is asking of nasty, unreproducible and incomprehensible bug
> reports.
Of course that is something packager must pay attention. But this risk
is manageable for the case discussed.
> > This way user will not be forced to download same package again.
>
> If you want to minimise the download bandwidth, try using a local mirror
> and using rsync. i.e. symlink the old .deb to the new .deb filename,
> rsync from the local mirror and then install the modified .deb.
I may have confused you.
This way user will not be forced to download another documentation
package in which only the version number is bumped. That is waiste for
everyone and can not be solved by local mirror nor by local cache
server.
Osamu
Reply to: