For me the deciding factor is that my entire set of build scripts
took me less than an hour to write. I gave up on Koji documentation
after about an hour because there just seemed to be far too many
moving parts involved.
Fancy becoming a RSEL Koji maintainer? What are the resource
requirements (CPU, RAM, disk)? I could easily enough spin
something up and get you ssh access to it (<= 512MB DreamPlug,
1GB -> 4GB I could probably get my Arndale OCTA or Cornfed
machine up and running next weekend (I've had them gathering
dust for a year, could rather do with the extra motivation to
get them up and running), or if you need more than that,
anything up to a fairly beefy x86-64 VM could be provided
easily enough.
Let me know if you're interested. Maybe it's time to switch
to Koji, if what you are saying is correct. Even if you could
just comprehensively document the installation process for the
wiki, it would be really useful.
Gordan
On 2015-04-09 15:20, Bjarne wrote:
Hi Gordan.
I have focused on using standard components as much as possible.
I saw how the RPMforge died out. I believe it was mainly because it is
always really hard to take over custom made solutions like Daag's DAR
system.
I am new to Koji and do not quite get it yet, but I have an initially
solution working.
One cool thing about Koji is it is like a virus. It is so super easy
to set up new build slaves. So if somebody has system available which
is accessible by SSH and can install EPEL packages it can be an Koji
slave in no time.
I agree that Koji is rather undocumented, or I have not found the
complete documentation. Taking bits and pieces from pages found by
Google.
So about the dependency issue I have not an answer to that since I do
not know.
And since Fedoraproject use Koji, so do I. I will not use time to
invent the wheel over again :)
And since CentOS have been adopted by RedHat i guess that it might be
used with Koji.
So, I can not say you should use Koji. Just think about if you should
have other people to participate or take over your build system :)
BR,
Bjarne
On 09-04-2015 11:58, Gordan Bobic wrote:
I have to say I found koji to be a major pain in the backside last
time I looked it - to the point where I abandoned it in favour of
abut 50 lines of bash scripts that produced results every bit as
good using mock (which koji builds use anyway) as using the
monstrosity that is koji in to drive it.
One killer feature that I had hoped koji would have is dependency
analysis (look at what packages have which dependencies and direct
the builds (--with bootstrap if required) in a way that avoids
tons of unnecessary package extraction/cleanups for all the
packages that don't have all the dependencies built yet.
Unfortunately,
koji does not in fact have such a feature, so I could not for
the life of me see what it brought to the table to justify the
complexity involved. So I abandoned the idea and stuck with a
few lines of bash that worked just fine.
Unless, of course, you are about to tell me that koji has gained
the said feature in the past 3 years or so...
Gordan
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
