On Mon, 15 Oct 2012, Anthony Towns wrote:
----- Original Message -----
From: "Seth Vidal" <[email protected]>
https://fedoraproject.org/wiki/User:Skvidal/BuildSystem
Interesting stuff!
When last this was discussed the koji maintainers were fairly
adamant that the above use cases was definitely outside
of the scope and goals of koji (which is entirely appropriate given
what koji does and how it does it).
The page above talks about modifying kojira and using koji builders; are
you thinking of expanding the koji source or adding plugins or similar
to allow running a different type of service on a separate machine to
koji.fedoraproject.org but based on the koji code; or would "outside
koji's scope" mean redoing the code to have an entirely independent
coprhub/coprbuilder setup and so on?
no - the goal of that is just to make koji builders more flexible so you
can add/remove them without having to jump through a bucnh of hoops. This
would give us more instances to use for either koji or these builds simply
by recreating the instance with a different profile.
Right now our builders require this ridiculously manual step of disabling
the koji builder, waiting for builds to finish, then being able to
reinstall/repurpose the instance. I'd prefer koji handles builder death
more gracefully. Right now it cannot cope without manual intervention.
What's the expected lifetime of repos and packages within copr repos?
It's potentially long term, right? eg build an add-on for f18 during
f18's beta, and keep it around until f18 hits end of life? That seems
the biggest departure from koji scratch builds; and the potential for
different builds with the same nvr is obviously the biggest departure
from koji's normal concept of builds.
A while. We've not settled on a time for those. Additionally, we support
external repos for the build process. External, untrusted, repos.
Is it a desirable feature to be able to pull in a prebuilt rpm that
someone else has built in their own copr -- if you've already spent five
days getting the latest libreoffice backported to f15 for arm in a copr,
and I want to build something on top of that, it seems a waste to do a
five day rebuild; but on the other hand, if copr/koji doesn't keep track
of all the old builds, how could it tell I'm giving it a legitimate
previously-built-from-source rpm, and not a GPL-violating, malware
loaded, evil binary-only rpm of doom for it to install in the build
root?
Yes - the coprs takes additional external repos and koji doesn't.
Coprs doesn't try to know about the repo or about the pkgs. They are
entirely untrusted. The source rpms will be checked for appropriate
licensing. But for packages which are buildrequirements I don't see how
that's important. We're not hosting or making them available.
Support for untrusted repos is why the builders have to be disposable.
You want to infect/damage a private cloud instance? great - have a
blast - it will last until the timeout for builds (1 hour) or it until your build
completes - at which point it will be terminated.
That's the whole reason we have laid it out this way.
BTW, https://copr-skvidal.rhcloud.com/ links go to
http://coprs.fedoraproject.org/repos/... which don't seem to work at the
moment? Is that deliberate, or a url bug?
Doesn't for me. It goes to the copr-skvidal.rhcloud.com page.
FWIW, to me this seems about as within koji's scope as the maven support
is -- maybe it means database changes and different builder setup and
isn't something that Fedora supports per se, but it's still providing a
controlled system for doing builds and managing the results... YMMV
obviously!
Not sure who you've talked with about this but the layout of koji makes
this pretty much impossible. Moreover we do not want to have to know what
the external repos are before we build from them. And we want to protect
our official builds from any possible compromising package.
-sv
--
buildsys mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/buildsys
