* Modestas Vainius <modes...@vainius.eu> [090822 15:36]:
> Nice. That's exactly I wished for. Btw, is flood fast, isn't it?

Do you mean that it is fast or that it is not fast?
There is some possibility for more optimisation, which I did not yet do
as I tested with a copy of the lenny distribution and the actual work
of flood was only a small fraction compared to then writing the Packages.gz
files that have changed afterwards.

> I guess my new processincoming .changes script will need to do the following:
> 
> ------------
> ls -1 "$INCOMING/"*.changes 2>/dev/null | while read f; do
>   distribution=`grep '^Distribution:' "$f" | sed 's/^Distribution:
> [[:space:]]*//'`
> 
>   # Make the latest arch:all packages apt-get'able
>   reprepro -A archall include $distribution $f
> 
>   # processincoming with limit_arch_all
>   reprepro processincoming ruleset $f
> 
>   # Make sure arch:all packages are in sync
>   reprepro -A archall flood $distribution
> 
> done
> ------------

I think it should suffice to just do

>   # processincoming with limit_arch_all
>   reprepro processincoming ruleset "$f"
>
>   # Make sure arch:all packages are in sync
>   reprepro flood $distribution

As archall is just one architecture to flood also put the
architecture all packages there (and as long as you do not
manage to upload _archall.deb files, flood will just put
every architecture all package it finds in there).

> This is a LOT easier than my previous big processincoming script with dynamic
> pull hacks etc. However, I'm wondering if I could do the first and the last
> command from Log --changes script using distribution=$2 (like below)? Is this
> thing safe to do when processincoming is active and a bunch of changes files
> are being processed? --waitforlock maybe or I should "schedule" them in the
> temporary file?
> 
> ------------
> ARCHALL="archall"
> distribution="$2"
> source="$3"
> 
> # Make the latest arch:all packages apt-get'able
> reprepro flood $distribution $ARCHALL
> 
> # Make sure arch:all packages are in sync if this was binary-only upload
> reprepro -A archall flood $distribution
> ------------

Doing that from Log will not work, as long as reprepro is still running,
the other reprepro will not work. and reprepro waits for the logs to
finish (as it only deletes to be deleted files after the log is
completed, so those scripts can look at them). So if you want to do
something like that you need to fork in the background and wait for the
logfile to vanish.

Also note that running flood when there is nothing to do should not harm
(only some looking, no new index files or other stuff).

Also note that while
> reprepro flood $distribution $ARCHALL
> reprepro -A archall flood $distribution
is different from
> reprepro flood $distribution
, the only difference is most likely nothing you care for:
With the two commands, only the newest version of an architecture all
package will be added to other distributions. With one command, if an
architecture has a newer a newer architecture specific binary than the
architecture inspecific package it has, but older than the newest
version of said architecture inspecific package has, there is a chance
this medium version will end up there (unless this architecture also
has a binary of the newest source version, then it makes no difference).

> I'm wondering if the first command will work since the dummy $ARCHALL
> architecture may not have the source yet. Therefore, could you make 'flood' to
> accept another optional parameter 'source package' which would limit queries
> to that source package and install its arch:all to $ARCHALL even if the source
> does not exist there?

flood does not look at source packages, only at binary packages.
It will put the newest version of an architecture all package in some
architecture, unless the new version has no architecture specific
sibling (a package from the same source-version) but the old one has).

Hochachtungsvoll,
        Bernhard R. Link



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to