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
> 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.
> 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.
-Just some thoughts I had, hope it's not too crazy.<br>
---Cameron
+>> 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]]
+[[!tag wishlist]]
sipb-www / ikiwiki.git / blobdiff