On 20-11-2013 11:03, Mark Trompell wrote:
So from what I get from the talks on irc, we're not yet ready to let
foresight die (which is good I think),
that leaves us with ~ 3 options. Lets sum them up:
a) We build our own from scratch base system and maintain it ourselves.
This will need a lot of manpower and disciplin to keep it running,
uptodate and maintained for every single package in there.
b) We define what our base is and just wrap them (no rebuild just
repack the rpms)
This will give us a well maintained system (e.g. fedora) that we can
build anything else on.
We won't need a bootstrap for this.
As far as I understood, mirrorball can help us there. This is pretty
much the boot approach we know from some time ago.
c) is some sort of hybrid, we don't just fetch and repack the rpms but
fetch the srpms and rebuild them.
Mirrorball has its part here too. Not sure of the details yet. Is it
possible to just use rpm build tools to build from specfile and use
the result?
But I want to get the discussion to be on the mailinglist, so that it
is persistant.
Any thoughts and Details welcome,
Mark
Just a quick note that I have captured the IRC logs in full and have
edited them for continuity. However, Mark's summary above captures
almost everything said, so I see little reason to post them here.
The only thing that I can see is missing is that António emphasized that
mkj's thoughts would be very valuable, as he is the de facto 'keeper of
the hennery' (i.e. the infra) as António put it.
With respect to option c), I haven't seen meeuw around for a while, but
maybe it would make sense to try to get in touch with him and hear how
his condora project turned out? As I understand it, mkj's original
'boots' proposal does indeed map onto option b) and meeuw's condora
approach maps onto option c).
It is worth mentioning that mkj pointed out that there was a lot of
busywork involved in wrapping binary packages in conary, so I'm not sure
what the value proposition is in option b) if option c) requires the
same amount of manual work yet gives us slightly more control.
FWIW, I think option c) is what we should go for if at all feasible.
Then we could keep working on option a) as a pet project which, while
insanely cool in and of itself, may or may not turn out to be useful in
a production context.
/Rune
_______________________________________________
Foresight-devel mailing list
[email protected]
https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
