X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/4fd800c06b3573175a334bd19030f39964d62d2a..ab4f499c8d903b3e66655b42202a29ece975112b:/doc/todo/parse_debian_packages.mdwn diff --git a/doc/todo/parse_debian_packages.mdwn b/doc/todo/parse_debian_packages.mdwn index 1001b9c9f..2425645d9 100644 --- a/doc/todo/parse_debian_packages.mdwn +++ b/doc/todo/parse_debian_packages.mdwn @@ -8,6 +8,13 @@ a helpful index page to a small repository, listing all the packages, and possibly their descriptions as well, with links to download them or their sources. +--Cameron + +> It's a good idea, I think there are probably several ways to approach it +> that would all yeild good, though differing results. Maybe with +> something like this I'd actually get around to posting ikiwiki debs to +> the repo. ;-) --[[Joey]] + I think this is easily possible (and I might be able to work on it myself, though Perl is not my strong suit). The trickiest part is probably figuring out how and when to parse the packages. @@ -18,6 +25,25 @@ reprepro/debarchiver/etc.). Or, the packages could be kept separate, with only a link given to the plugin, though changes would then not be picked up until the ikiwiki is recompiled. + +> This could be done by adding a hook to reprepro/whatever that calls +> ikiwiki --refresh at the end of updating a repo. (I don't +> remember if reprepro has such hooks; mini-dinstall certianly does.) + +>> reprepro doesn't seem to have one, :( though of course creating a +>> script to do both would work (but it's not optimal). --Cameron + +>>> reprepro has two kind of hooks that could be used. One is called +>>> whenever a Packages file is changed (normaly used to generate +>>> Packages.diff files, but it does not need to add new files). +>>> The other (though only available since 2.1) is called whenever +>>> a package is added or removed (there is an example in the docs +>>> for extracting changelogs using this). + +> For ikiwiki to notice that the Packages file outside its tree has +> changed and things need to be updated, a `needsbuild` hook could be +> used. This seems very doable. + Perhaps a better (though infinitely more complicated) solution would be to include the reprepro/debarchiver functionality in ikiwiki. Packages could be posted, like blog entries, and tagged @@ -25,5 +51,20 @@ with the target distribution (sid/lenny/etc.). Then compiling ikiwiki would generate the needed Packages/Release files automatically. -Just some thoughts I had, hope it's not too crazy.
---Cameron \ No newline at end of file +> I like the idea of +> using packages as "source" and spitting out apt repos, though I'd not +> want to use it for a big repo, and I'd ideally want to keep the packages +> in a different svn repo, pulled in via svn:externals. + +>> I like it too, more than the easier options, why are the most +>> interesting solutions always the most complicated? ;) + +>> Parsing the files sounds like it might require some outside +>> dependencies, and given the complexity maybe this should be +>> a separate package from ikiwiki. Is it possible to package +>> plugins separately? --Cameron + +>>> Sure, a plugin is just a perl library so can easily be packaged +>>> separately. + +[[!tag wishlist]]