On 11/28/2014 12:18 PM, Patrick Ohly wrote:
On Fri, 2014-11-28 at 08:52 +0000, Counihan, Tom wrote:
I think some words on how the workflow from an external consumer would
be beneficial?
I understand we cannot be prescriptive, as each may have different
internal workflows, but which might be interesting is does the model
place any constraints on their workflow? Maybe there is none.
First, let me point out that we currently don't have a good story for
someone taking Tizen and modifying it for their purposes.
One approach is to use "gbs build" locally. Various people have tried
and failed; it may be better now (see the "Local Full Build Report"
emails on this list), but gbs is still not designed and meant to rebuild
the entire distro from scratch.
The other approach is to setup a stock OBS instance and import the Tizen
project from build.tizen.org. I don't know how many people are able to
do that, and we don't have any documentation for it. Replicating the
Tizen "git tree -> gerrit -> OBS" process would be even more work.
This is where "Tizen on Yocto" comes in. To me, the main reason for it
will be that it will enable anyone to clone the Tizen packaging meta
data and build a potentially modified image on a Linux box with minimal
requirements for prior system setup (essentially just a compiler, make,
Python). Yocto also has extensive support for common release activities:
* license checking
* publishing source
* creating an SDK
* archiving the distro build environment
As discussed in the other thread, neither "gbs build" nor OBS go away,
so those options remain for someone who wants to go down that path. But
IMHO using Yocto instead is the better alternative.
What is the vision of an external product vendor for example working
with this model expected to operate?
For example, the last step in the diagram is the download server - so
is that the egress for them?
"egress" = the outcome of the Tizen build process and thus the input for
external product vendors? They could take the .src.rpm and rebuild them
with rpmbuild, but I wouldn't say that this is the right approach, so
no.
Is it expected that they replicate the picture internally? They will
probably be forced to.
No, only if they want to work exactly as Tizen does. That's probably
overkill for most vendors.
Should the build against pre-build binary rpms, or rebuild themselves?
Depends on their needs. If I were to build a product, I wouldn't rely on
someone else's binary rpms unless I had verified that I can rebuild them
myself should the need arise.
IMO if a vendor wants to modify Tizen (Yocto) to match its needs the
best approach would be to create its own layer containing the
modifications. This layer would be external and could be managed the way
the vendor wants, following its own internal process. (In fact this is
how Tizen (Yocto) is currently managed but we're moving to a full
distribution instead of a layer.)
Kevin
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
