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

Bug#1402: New version of pdpkg, new Packages file



I finally got fed up with the deficiences of `pdpkg', and have written
a new version.  I have put it in project/experimental/npdpkg.

You will also find there a file `nPackages' which is its output.  I'd
like people with recent versions of dpkg to try downloading it and
using it with the Update option from the dselect menu (use Access to
specify where it is) or using dpkg --merge-avail, and then try seeing
if the dependency and conflict screens dselect produces make any kind
of sense.

Ian M.: the script takes two arguments.  The first is the name of the
`binary' directory containing the .deb files; the second is the name
of an `noverrides' file in a slightly improved format - there is an
example in project/experimental/npdpkg.  There is also an `over2nover'
script that converts one to the other.

The script uses `find' to find the files, and then extracts the
control information using dpkg-deb -I foo.deb control.  It puts
together the information from all the available files, and then
overrides the Priority, Section and possibly Maintainer from the
override file (the fields are in that order, separated by spaces or
tabs).  It's supposed to check that the .deb files are in the
directories corresponding to their Section.  It writes the new
Packages file to stdout.

It *doesn't* do a full syntax check on the Packages file which
results.  It would be good to do so, but that would require
modifications to the dpkg source that I don't have time to make at the
moment (the dpkg source tree contains the library for parsing Packages
files, control files, &c).  In any case, it's very hard to make new
packages that are broken without noticing, because dpkg-deb will moan
at build time.

To integrate it into your nightly cron job you should write a script
that has it build the new Packages file and then uses mv to do an
atomic overwrite.  Don't do
  rm -f Packages
  mv Packages.new Packages
because then there's a moment when no Packages file is available, and
by sod's law this will happen when a mirror site gets the directory
listing.  Instead, do
  mv -f Packages.new Packages
  rm -f binary/Packages.new
  mv -f binary/Packages.new binary/Packages
  rm -f ms-dos/Packages.new
  mv -f ms-dos/Packages.new ms-dos/Packages
or whatever is appropriate.

Don't forget the non-free and contrib directories.

dselect would prefer the Packages file to be in the `binary'
directory for each area (ie, /debian/binary/Packages,
/debian/contrib/binary/Packages, /debian/non-free/binary/Packages);
whether you put an additional copy of each just above the first is up
to you.  Please do put in a README saying that you need a different
Packages file for each area.

Ian.


Reply to: