Re: Koji, mock, fedpkg, etc?
От | Devrim Gündüz |
---|---|
Тема | Re: Koji, mock, fedpkg, etc? |
Дата | |
Msg-id | 1406579479.5202.4.camel@asus-laptop-03.gunduz.org обсуждение исходный текст |
Ответ на | Koji, mock, fedpkg, etc? (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: Koji, mock, fedpkg, etc?
|
Список | pgsql-pkg-yum |
Hi, On Mon, 2014-07-28 at 12:36 +0800, Craig Ringer wrote: > I've been looking into ways to streamline packaging, as I'm going to > need to be rolling on-demand packages soon and want to stay as close as > possible to PGDG. > > In the process, I've noticed that the PGDG yum/rpm packaging team seems > to have a lot of homebrew infrastructure that duplicates facilities > provided by Fedora/RH. For example, the use of Jenkins for package > building instead of koji and mock. We don't use any of the automated tools. Right now, there is *almost* zero automation. At 2007, when I started the yum repository project, I and Darcy (Buskermolen) tried to install koji a few times, but honestly we could not succeed. Then, gave up. > I've been taking the same approach as PGDG to date, as I only just > became aware of Koji and mock, as well as the ancillary tools like the > koji command line client, rpkg/fedpkg, etc. I really love koji -- at least when I use it for Fedora and EPEL packaging. > Have these tools been specifically looked at? I'm wondering if they > might make package building/maintenance easier. TBH, I am not that eager to use automated tools -- at least the signing process needs manual work. Still, I am open to ideas of course. > My only concern with Koji is that it doesn't seem friendly toward > low-demand dynamic package building, where VMs for package building are > launched on-demand and shut down after use. OTOH, I might simply not > have noticed a relevant tool or plugin yet. FWIW, our VMs are never shut down, and IIRC koji can work with it. > I thought I'd ask here and solicit opinions/experience, in case > someone's already looked into this toolset and concluded that it doesn't > meet PGDG packaging needs. Or, if it's unfamiliar, find out whether it > might actually help solve any current challenges with maintenance. Well, I think Jeff should also say his opinion. So far, I am pretty happy with what we have now, since I am used to it -- which also means that I may not be aware of the abnormalities of the process. Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Вложения
В списке pgsql-pkg-yum по дате отправления: