While thinking about this problem over the Christmas break I have come to the conclusion that we do not have to change the filenames so that we can recover the package name and version information from them.
Programs can use the Packages file to avoid downloading files that they know they don't want (because of the Filename field there). If a package has just been moved into view and the Packages file isn't up to date yet then they will have to download just enough of the package to get the control information and can then abort the transfer. Because most of the schemes for making the filenames contain the package name and version without any ambiguity are ugly in some respect I'm inclined to say that this is what we should do. There is another problem with encoding things like this: it means that if at some later point we want to put some new information in the filename (such as the target architecture) we can't do it because it will break dftp and the dselect FTP method. There are a couple of things I want to set people straight on, in this area: * dpkg and other packages written especially for Debian don't have a revision number because a revision number would be meaningless and confusing. The most recent guidelines say not to use the Revision field anyway (as it will be phased out soon) and say that only packages not written specially for Debian shouldn't have a -<revision> component in their Version field. * Changing the format of version numbers in existing packages causes problems, because dpkg can't tell whether the package is a downgrade and so can't tell whether to install it. * Noone (hopefully) is proposing changing the actual package names (as seen inside the package control file), so consideration of Provides fields as a backwards-compatibility measure is missing the point. Changing package names is quite a serious and risky operation for an already-installed system, and should be avoided where at all possible. * Someone said that we don't need to parse the version number out of the filenames. They were wrong. dftp and the dselect FTP method need to know the version numbers of packages they're thinking about downloading, so that incremental upgrades don't have to fetch all the selected packages but only the changed ones. * There is little point trying to keep our filenames completely consistent with the upstream maintainers'. In fact, upstream maintainers' filenames are frequently very inconsistent across packages, and we want to present a consistent filename format for neatness. * If we do want to rename all the .deb files we don't have to do it all at once and screw up the mirrors. Just rename half a dozen files each day until they're all done. * Revisions are allowed to contain `.' characters. See the packaging guidelines. * A SITE EXEC command is no good because we can't rely on it being supported everywhere. It's also quite inefficient. * Bruce said: > Once we decide on a package naming standard, we should tell the rest > of the free software world what it is and encourage the upstream > maintainers to stick to that format. There already is a de-facto standard for general naming of upstream source packages - it's the one used by the GNU people, <package>-<version>.tar.gz. Ian.