Re: DAK (2)
On Mon, Dec 09, 2002 at 01:21:09AM +0000, James Troup wrote:
> Brian May <bam@debian.org> writes:
>
> > I looked at katie; it seemed to be a complicated and undocumented
> > mess that was a total overkill for my purpose (eg. I don't need a
> > database).
>
> That "complicated and undocumented mess" has been running the Debian
> archives successfully and without major incident for over 2 years now;
> it must be doing something right.
If I were to clean things up and make DAK easier to use for private
archives (eg. by isolating all Debian specific stuff, ideally into
a limited number *.conf files), would somebody be willing
to commit the changes to CVS?
I suspect even though I might have write access to CVS, I don't wont to
commit anything in case I break something ;-).
> like doc/README.names maybe.
I found that very brief and vague. It is not made clear for instance,
what programs must be run before, what CWD must be in order to
run the program, etc.
Command line parameters are simply not documented anywhere.
Some questions:
1. For package installations, DAK will inform both the uploader and the
maintainer. For private archives should it inform the maintainer?
Maybe a message "Your package has been installed in the private
archive at http://.../ and has SE-Linux support" might be good, and
clearly indicates that the package maintainer doesn't have to panick
about a non-authorised version being uploaded to Debian.
2. Where is the code that moves unstable to testing? That does not
appear to be here?
3. Could the information in apt.conf be automatically generated from
kate.conf? It seems very much like apt.conf just duplicates
a lot of information in the Suite section of kate.conf, and I dislike
duplicating config information (it increases the chances of a
mismatch).
4. When installing a new package (with lisa I think), how do you specify
with component {main,contrib,non-free} it will go into?
My plan to improve the code would be (not sure how feasible this is
just yet):
1. mkdir examples/{ftp-master,non-US,security}.
2. move all files specific in anyway to ftp-master to
examples/ftp-master, same respectively for non-US and security. eg
aot.*, update-* and cron* would appear to be good candidates.
3. Create "clean" cron job utilities that are not specific to the
computer, and extract required information from database and/or
config file.
4. Documentation for getting started.
5. Debian packaging.
Anyway, just some ideas. I am not sure if there is a dedicated
mailing list for this or not.
--
Brian May <bam@debian.org>
Reply to: