Following Martin's reflections here is my take...
a) 'boots' is just a repackaged fedora, bit by bit, bug by bug, similar
in behavior to stock fedora.
you can package/cook/build plain conary custom recipes against a
stock boots context and
they will happily build on top of 'boots'
b) As boots is what it is, I don't foresee a lot of direct
modifications, if any, on top of it, as goal is to
just do a good job tracking upstream fedora moves, so the point of
getting 'native' boots
packages built is lateral, as the only thing that matters is that
the contents of those packages
is exactly the same as the one of the matching rpm ones. (with that
said, it is possible to pipe
rpmbuild into our native build tools, and so allow one to play
directly with the original rpm spec
files. why would one do that when we have recipes is another story)
c) Foresight is a very different kind of beast. We control/build it
from the ground, no strings attached.
Just for economy of resources, what is on top of table, is to
strictly follow (where it makes sense)
what is in fedora/boots (built from conary recipes) to avoid extra
overhead, and _until_ we get proper
resources to do it all on our own. Ideally one would just track
upstreams, but that burns time we don't
have, so for the areas we are lacking, we 'd just _for_ now fedora
as an upstream. (there are areas
like gcc/glibc where they are really upstream), just leveraging
their work, pure open source style.
For a multitude of reasons, reinventing the wheel yet again wont
take us anywhere,
d) As we don't expect to get a toolchain team to do our own mods to
gcc, at very low level ABI compatibility
is assured. At higher level, we will avoid to make gratuitous
changes, but of course that we will get things
that work on one side but not on another (as we tend to be more up
to date)... With that said, and given
that usually most major subsystems tend be keep some kind of back
compatibility, what i expect is that most
of the the stuff from/built against boots will just work on top of
foresight3.
e) fwiw, I do not plain do run boots myself, at least, outside of the
scope VM. The main value is see from it, frankly,
is to give us a straight/cheap path to the tons of stuff already
packaged for fedora.
f) re; rpm. I don't like rpm - ok i just said it, i don't like debs,
said it too. But i can't change reality, Fair or unfairly they
are the standards in the world we are, right now. We can either be
reformists, or revolutionaries, A revolutionaire
ignores reality and just tries to shape things at his will - among
other things, we DO not have enough resources,
to be revolutionaries, so we need to be sneaky, get creative, and be
'reformists', getting ways to digest all the
rpm infrastructure around, which is sadly and right now still the de
facto standard, and get and upgrade/escape
path from it. having rpm and conary side by side, in a given setup,
isn't the end of the world as mkj and Andy noted,
it isn't either the most beautiful solution either. Not, until some
one glues both either at low level (it wouldn't shock me that someday
we got a genetically engineered rpmlib that would suck/plug into
conary directly, having both conary and rpm userland
to share same db (with rpm obviously using a limited subset of
conary can of tricks), or thru, for example, pkgKit integration
g) overall what is going on are 'just' two major things - first, an
effort to streamline foresight development, and focus, in order to allow us
world domination, which is, as usual, the goal, and second, an
effort to make foresight, as a distro and as a community, benefit from
the plain fedora rewrap, that will happen one way or another( as the
tools exist, work, and is 'cheap' resource-wise) integrating
that effort, from the start, under the foresight umbrella.
h) If i had to choose, right now, a tagline for the choices one will
have to face, daily, on foresight-land, that would be ...
""" At any given time, not try to provide the "best new technology
of tomorrow", but the best "*working* technology of today" """.
All the best,
António
On 08/26/2009 05:46 AM, Martin Baehr wrote:
> On Tue, Aug 25, 2009 at 05:41:20PM -0400, Michael K. Johnson wrote:
>
>>> i am also concerned that a binary import of fedora will be very very
>>> dificult to reproduce in terms of GPL obligations.
>>>
>> The tool is set up to commit the SRPM with the original binary RPMs as
>> the conary source package. It's easier to fulfill GPL obligations with
>> a conary re-packaging of Fedora than it is with a simple mirror, because
>> you know that as long as you have the binaries, you have the sources;
>> there's no chance you'll accidentally delete/loose the SRPMS directory
>> and (oops) be out of compliance.
>>
> just having the sources is not enough. how do i rebuild the binaries
> from those sources?
>
>
>>> i don't see any other way because if i build the package from source
>>> instead i will get something different alltogether (since it is now
>>> built with a different toolchain, against a different set of
>>> libraries (some rpm imports and some not)
>>>
>> It would be built with the same toolchain and against the same
>> libraries (as imported into a Conary repository). We know that
>> this works because we already do this for CentOS, Scientific Linux,
>> SLES 10, SLES 11, and Ubuntu Hardy (as a beta import). It's hard
>> for me to address this objection more directly and meaningfully
>> because I don't understand any context in which it is true. :)
>>
> that is only the case for a pure binary import that does not include any
> mixed updates. i am looking at the situation of importing binaries into
> a mixed foresight system. those binaries were built on a fedora system
> but now run on a foresight system with a different set of libaries
> available. how can i rebuild those binaries and get identical results?
> i do not think this is possible unless i build them on a pure fedora
> system using rpm build tools.
>
> greetings, martin.
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
