(Crosspost to debian-user removed.) Bruce Perens writes ("Re: Autorename packages/add a filename field in packages-master "): > [EMAIL PROTECTED] 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.