On Fri, 3 Oct 2008 01:47:51 +0900 Osamu Aoki <osamu@debian.org> wrote: > I know there is a way to do it ?? On what basis? Which packages? Are you confusing porter uploads using dpkg-buildpackage -B ? > 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 This trick should not be necessary (or used) - not with the current toolset. Translation packages are completely separate and TDebs (which I am developing within Debian for Squeeze) will use a different method. > 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. That is not the same thing. It can be used to correct certain errors but, AFAICT, it is not intended for routine usage. > * Is this still useful technique? Not for you want to do, no. One-off fixes might be necessary but not for packages discussed on this list. > > 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? Yes. I run several repositories. You are describing a native package in your example. The .tar.gz will be removed when a new version is uploaded - the only time it will be retained is if the old version exists in a different distribution, e.g. testing. As soon as the package migrates, the source will be removed. The .changes file you describe will try to correlate the 1.0 package with the 1.1 source (due to the changes file and .dsc itself being 1.1) which is simply incorrect. The problem gets worse with non-native packages when a new upstream release is made. Keeping the gcc source package around for various versions according to the state of various packages built from the gcc source that haven't changed - I can't really see the ftpmasters liking that idea. It is also hard to ensure that maintainers correctly synchronise the packages - you'd need a whole new process to check the content that would have been included against the content still packaged in the old version. I don't see that it is worth investigation at this stage and certainly not on this list. Take it to debian-devel if you want to start work on the various fixes and scripts that could be necessary to make it sane. > 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. That is just plain broken. > > 2. Keeping the source around is not sensible across 20,000 packages. > > Sure but that is not the issue. Of course it is. The archive managers do not want extra source versions hanging around and without extra source versions, the archive is illegal. > > 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. The package will not contain the modified changelog. The changelog was modified *AFTER* the 1.0 was built and only exists in the 1.1. The changelog is part of the legal source under some (free) licences. > > 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. Of course it can - the local mirror is shared between various users and those users can use rsync. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgp1CDUNjk2v3.pgp
Description: PGP signature