Re: FTP Installation & Package Naming Conventions
(Crosspost to debian-user removed.)
Bruce Perens writes ("Re: Autorename packages/add a filename field in packages-master "):
> branderhorst@fgg.eur.nl said:
> > add Filename: field in Packages-Master
>
> I think the script that generates the Packages and Packages-Master files has
> all of the information it needs to add a "Filename:" field to the database,
> probably with no more than a one-line modification. The filename should be
> relative to the "binary" directory.
>
> This is necessary to make the FTP method of "dpkg" work. The alternatives are
> all _much_ more ugly. Could you put this feature in?
Thanks everyone for coming up with a good solution. I've now
implemented this, and a test run seemed to do the right thing. It was
about 6 lines' modification, in all, because I'm paranoid :-).
The filename is *not* relative to the `binary' directory, because it
would then be unhelpful in the Packages-Master file. It's relative to
the root of the archive. So, for example, we have
Package: dpkg
Filename: debian-0.93/binary/base/dpkg-1.0.5.deb
This is in both Packages and Packages-Master (Packages-Master is a
simple concatenation of the debian-0.93, contrib and non-free Packages
files).
See below for how I think the `ftp' method should handle things.
> If you wanted to be ultra-generic you could add a "Filename" and a
> "DOS-Filename" field, but this is probably not necessary.
I agree, and in any case this would be a lot more work, because I
don't currently scan the msdos tree.
brian white writes ("Re: FTP Installation & Package Naming Conventions "):
> How about another field in "Packages-Master" called "Filename: ..."?
>
> Of course, the "Packages-Master" file is usually missing descriptions
> of some packages that are available. This would have to be fixed.
> Also, because it is a derived work, it would have to be generated
> after all changes have been made for the day and _before_ the mirror
> sites drop by to gather the newest image. If not, you end up with a
> list that is a day behind and the fetch program could fail due to the
> inconsistancies.
Ah, but there is a solution to this: only use the Packages file as an
optimisation to avoid downloading files you know you don't need.
Conceptually your algorithm should be:
For each .deb file found under the binary directories being searched,
check whether the file is listed in the relevant Packages file.
If so: Download and process it only if the package, version and
status information from dpkg's database and from the FTP site mean
that dpkg would process it if the file corresponded to the entry in
the Packages file.
If not: Download and process it anyway.
I have code in the dpkg source tree that can be used to process fields
in the Packages/control-file format that all these programs use to
talk to each other. If Brian would like to tell me what order he'd
like to feed the data in and how he'd like the results to be
communicated (eg, run dpkg-<something> to cache the Packages data
somewhere and then run dpkg-<somethingelse> and test the exit status
to see if a particular filename warrants inclusion, or run
dpkg-<otherthing> to turn a Packages file into a list of filenames to
be skipped, or whatever) I can easily write the programs for this in
C.
I think the FTP installation method should ask you whether you want to
try the `bleeding-edge' tree or the `stable' tree, and should use the
appropriate links on the FTP site together with the `PWD' command to
find out which trees to process.
brian white writes ("Re: FTP Installation & Package Naming Conventions "):
> I'd prefer to standardize the filename, but I don't think people are willing
> to do that.
I think that's a lost cause, I'm afraid.
Kai Henningsen writes ("Re: FTP Installation & Package Naming Conventions"):
> Incidentally, I've been meaning to ask - how do you make a Packages file?
There's a script on the FTP site that does it.
> Wouldn't it be a good idea if one could regenerate one locally?
One can do almost the same thing: you can use dpkg -A on a directory
full of .deb files to update the `available packages' info in
dselect. I don't know if anyone actually uses that option ...
Generating a Packages file is not that easy, because it contains
information not found in the .deb files (such as packages' actual
priorities and sections). However, concatenating the control files of
the .deb files (extract them with dpkg-deb --info) would produce
something looking remarkably like a Packages file.
Ian.
Reply to: