Luke Macken (lmacken@xxxxxxxxxx) 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
