[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Update repository management


On Thu, Aug 26, 2010 at 07:27:48PM -0700, Russ Allbery wrote:
> > With such a system in place, we can then just schedule all our servers
> > to do an apt-get update; apt-get upgrade from the mirror and only get
> > the updates that have been approved to be deployed to that server (based
> > on which "distribution" it connects to).
> I don't think there's anything like that that's already built, but I think
> that you could build that on top of reprepro using both a pull list and
> then the reprepro commands for moving things between distributions.  You'd

Yeah. Or simple copy(src)'es. And maybe you also want to update's there
in case you have a update rule fo update from the base distro (we have that
for our -devel part)

We have that structure you describe too but currently it boils down
to one of the repository admins pull/copy(src)'ing on demand after QA..

> still have to write the web interface, since I don't think anyone's done
> that part, but I think it's only the UI that needs to be written and the
> reprepro commands will do nearly all the rest of the work.

Yep. That UI is something we miss, too.

What we in this case would need, though, is a *sane* way to access the reprepro
database. Because IMHO it's not desirable to try to get the data out of the
.db file. And reprepro list locks the db, too so when you want to find out
more complex things....

So I added a hook which copies the data into a MySQL database, which then
can be used for quickly looking what is where and which maybe can then
also be used as a datasource for that UI. (Or we evaluate libdb5.0s SQL



Reply to: