$HeadURL$ $LastChangedRevision$

code
====
    
for 2.0
-------

on macaroni, I saw this when paa was upgraded automatically overnight

    Date: Fri,  1 Feb 2013 06:25:11 +0100 (CET)
    From: Cron Daemon <root@pasta.net>
    To: root@pasta.net
    Subject: Cron <root@macaroni> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
    
    /etc/cron.daily/autoupgrade:
    (Reading database ... 41727 files and directories currently installed.)
    Preparing to replace ade 1.5-1 (using .../archives/ade_1.5.1-1_all.deb) ...
    Usage: update-python-modules [-v] [-c] package_directory [...]
           update-python-modules [-v] [-c] package.dirs [...]
           update-python-modules [-v] [-a|-f|-p]
    
    update-python-modules: error: /usr/share/python-support/ade.private is not a directory
    dpkg: warning - old pre-removal script returned error exit status 2
    dpkg - trying script from the new package instead ...
    Usage: update-python-modules [-v] [-c] package_directory [...]
           update-python-modules [-v] [-c] package.dirs [...]
           update-python-modules [-v] [-a|-f|-p]
    
    update-python-modules: error: /usr/share/python-support/ade.private is not a directory
    dpkg: error processing /var/cache/apt/archives/ade_1.5.1-1_all.deb (--unpack):
     subprocess new pre-removal script returned error exit status 2
    Usage: update-python-modules [-v] [-c] package_directory [...]
           update-python-modules [-v] [-c] package.dirs [...]
           update-python-modules [-v] [-a|-f|-p]
    
    update-python-modules: error: /usr/share/python-support/ade.private is not a directory
    dpkg: error while cleaning up:
     subprocess post-installation script returned error exit status 2
    Errors were encountered while processing:
     /var/cache/apt/archives/ade_1.5.1-1_all.deb
    E: Sub-process /usr/bin/dpkg returned an error code (1)
    run-parts: /etc/cron.daily/autoupgrade exited with return code 100

add epel example config (maybe for upstream and local) 
and add to autopaa

Something is wrong the trigger for blocking host deletion when there 
is still an accesss for it:

	[root@spaghetti yum.repos.d]# sqlite3 ~/.paa/paa.sqlite 
	SQLite version 3.6.20
	Enter ".help" for instructions
	Enter SQL statements terminated with a ";"
	sqlite> pragma foreign_keys = on;
	sqlite> update hosts set status = 'deleting' where host == 'spaghetti';
	Error: constraint failed
	sqlite> 

It should have produced a trigger-based error message, but
this is something else. And yet here it works:

	sqlite> select * from hosts;
	fettuce|available|deb|debian|squeeze|amd64|1357226150
	sqlite> update hosts set status = 'deleting' where host == 'fettuce';
	Error: REPORT_TO_USER: an access is referencing this host
	sqlite> 

bs should delete empty .queue directories

for post-2.0
------------

Would be nice if an insert didn't produce these repeated messages:

	epilogue-pkgctrl.pasta-net: INFO: paa_1.99.3-1_all.deb: inserting into lenny,squeeze,wheezy ...
	paa: INFO: paa_1.99.3-1_all.deb: analysing ...
	paa: INFO: localpublic-deb: paa_1.99.3-1_all.deb: copying to repository ...
	paa: INFO: localpublic-deb: paa_1.99.3-1_all.deb: copying to repository ...
	paa: INFO: localpublic-deb: paa_1.99.3-1_all.deb: copying to repository ...
	paa: INFO: localpublic-deb: paa_1.99.3-1_all.deb: copying to repository ...
	paa: INFO: localpublic-deb: paa_1.99.3-1_all.deb: copying to repository ...
	paa: INFO: localpublic-deb: paa_1.99.3-1_all.deb: copying to repository ...
	
(Submit it as a bug report later)

Should I block 'paa editrepo X' if X has a mirror (and a chain of other stuff)?
I'm really not sure.

docs
====

DB changes that need documented in the UML diagram:
	path@controls --> file@controls, dir@controls
	extendeds@paacrt_url_prefix --> extendeds@url
	directs --> indirects

Dia has a UML icon for static data (looks like a book with
hinge). Try it for the tables at the bottom of the diagram.

tests
=====

Add a new test that creates repos, mirrors, etc all
the way through to accesses. And then it tries to
remove them out of order. Like:

    DIRECTIVES=( unrepo unmirror ... )
    for ((I=${DIRECTIVES[*]}; I>0; I--)); do
        for ((J=0; J<$I; J++)); do
            paa ${DIRECTIVE[$J]} ...
        done
    done
    
(In the I-th loop, only the paa invocation with I==J
should work. I.e. the *last* highest-level un-whatever
should be possible, but only that one.)

Add a test that tries to run 'paa repo X Y Z' with invalid
X, Y, Z and see what happens. It should not produce constraint
errors, but rather trigger errors.

deb
===

autopaa was compressed not executable in /usr/share/doc/paa/examples