Luke Macken (lmacken(a)redhat.com) said:
By the looks of the fedora-release-tools module, there are two
scripts
that have been used to sign packages, ftsign and fedorasign, both of
which call /usr/local/bin/rpm-4.1-sign, which is a symlink to
/usr/lib/rpm/rpmk.
... which doesn't interact well with brew/koji.
Koji keeps a sigcache for each package in
pkg/ver/rel/data/sigcache/arch/,
although I have no idea at what point in the build process this gets
created. I'm also under the impression that just having this detached
signature isn't enough, and that there still must be some manual
intervention? Is there anything else bodhi needs to do other than make
sure the corresponding .sig exists for each package?
The sigcache is a koji feature; you can tell it to write out a
signed version of the package on demand. mash, at least, does
not do this, and will just take whatever existing version is
signed with the best key. (Waiting on it to generate signed
versions would be rather slow.)
This isn't as bad as the previous biarch-list-of-doom[0] anymore.
Bodhi
imports it into its Multilib database table[1] during initialization, and
doesn't deal with it again. Upon submission of an update, bodhi builds
the list of associated packages, taking care of multilib based on what's
in the db. The multilib table can then be modified with ease using the
TurboGears CatWalk database editor, or a simple command-line tool.
Still, it's a list - each new added package would potentially require
an addition.
> - rsync the whole repo out
TODO. At the moment bodhi stages to /mnt/koji/updates-stage -- where
are we going to sync this to? wallace still?
Short-term, yes.
> Older updates are cleaned by a cron script later.
TODO. We need something similar to the fedora-updates-clean script that
is currently in place (but less hackish), or RepoPrune / repomanage.
The TurboGears scheduler[3] is probably a good place for this. I'm
going to try and find some time tonight to throw one together.
Well, we *could* go to one-update-only, as older updates will be available
directly from the koji web server.
> Disadvantages:
> - multilib. In a world where we continually add new packages, this
> *will not scale*.
Random idea. Since multilib is handled by mash, which pushed out
rawhide nightly, couldn't we just have mash keep the Multilib table up to
date? Would this solve the scalability issue wrt new packages?
rawhide doesn't necessarily mesh with what's available for earlier
releases.
Bill