doc/todo/parse_debian_packages.mdwn

   1 A parser, similar in functionality to [[plugins/inline]] that would find
   2 and parse debian packages from a repository and include links to
   3 them. Functionality would be similar to the
   4 [PHP Apt-file parser](http://php-apt-parser.alioth.debian.org/)
   5 (for an example of the output, see
   6 [my repository](http://debian.camrdale.org/)). This would create
   7 a helpful index page to a small repository, listing all the
   8 packages, and possibly their descriptions as well, with links to
   9 download them or their sources.
  10
  11 --Cameron
  12
  13 > It's a good idea, I think there are probably several ways to approach it
  14 > that would all yeild good, though differing results. Maybe with
  15 > something like this I'd actually get around to posting ikiwiki debs to
  16 > the repo. ;-) --[[Joey]]
  17
  18 I think this is easily possible (and I might be able to work on
  19 it myself, though Perl is not my strong suit). The trickiest
  20 part is probably figuring out how and when to parse the packages.
  21 The packages could be included in the ikiwiki RCS repository,
  22 which might be difficult when the Packages/Release files need to
  23 be generated (especially if it's via an external tool like
  24 reprepro/debarchiver/etc.). Or, the packages could be kept
  25 separate, with only a link given to the plugin, though changes
  26 would then not be picked up until the ikiwiki is recompiled.
  27
  28
  29 > This could be done by adding a hook to reprepro/whatever that calls
  30 > ikiwiki --refresh at the end of updating a repo. (I don't
  31 > remember if reprepro has such hooks; mini-dinstall certianly does.)
  32
  33 >> reprepro doesn't seem to have one, :( though of course creating a
  34 >> script to do both would work (but it's not optimal). --Cameron
  35
  36 >>> reprepro has two kind of hooks that could be used. One is called
  37 >>> whenever a Packages file is changed (normaly used to generate
  38 >>> Packages.diff files, but it does not need to add new files).
  39 >>> The other (though only available since 2.1) is called whenever
  40 >>> a package is added or removed (there is an example in the docs
  41 >>> for extracting changelogs using this).
  42
  43 > For ikiwiki to notice that the Packages file outside its tree has
  44 > changed and things need to be updated, a `needsbuild` hook could be
  45 > used. This seems very doable.
  46
  47 Perhaps a better (though infinitely more complicated) solution
  48 would be to include the reprepro/debarchiver functionality in
  49 ikiwiki. Packages could be posted, like blog entries, and tagged
  50 with the target distribution (sid/lenny/etc.). Then compiling
  51 ikiwiki would generate the needed Packages/Release files
  52 automatically.
  53
  54 > I like the idea of
  55 > using packages as "source" and spitting out apt repos, though I'd not
  56 > want to use it for a big repo, and I'd ideally want to keep the packages
  57 > in a different svn repo, pulled in via svn:externals.
  58
  59 >> I like it too, more than the easier options, why are the most
  60 >> interesting solutions always the most complicated? ;)
  61
  62 >> Parsing the files sounds like it might require some outside
  63 >> dependencies, and given the complexity maybe this should be
  64 >> a separate package from ikiwiki. Is it possible to package
  65 >> plugins separately? --Cameron
  66
  67 >>> Sure, a plugin is just a perl library so can easily be packaged
  68 >>> separately.
  69
  70 [[!tag wishlist]]