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

dselect FTP method and dftp wrt FTP site organisation

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

* 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

* 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

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


Reply to: