Mailinglist Archive: opensuse-buildservice (199 mails)

< Previous Next >
Re: [opensuse-buildservice] Specification for OBS light project concept
  • From: "Dominig ar Foll (Intel OTC)" <dominig.arfoll@xxxxxxxxx>
  • Date: Mon, 20 Jun 2011 11:59:58 +0200
  • Message-id: <4DFF1A1E.8050806@fridu.net>

Le 20/06/11 07:36, Tommi Rintala a écrit :

I apologize for top- and in-between posting, and perhaps somewhat
naive thinking, but I just couldn't stop for my brains for making
stupid question(s):
The only stupids people are the one who do not ask questions :-)

Since most developer hardware are capable of running virtual
appliances (using Vmware's player, KVM, or other such software) would
it be out-of-reach of obs/osc developers to implement osc as VM client
node, which would register itself to OBS service as a build node.
Issue is that when you run an investigation project in a company to
select a new OS, your project is not public. It's actually in general
highly secret getting a local system is perceived as a high value in
that period.
Going an a public OBS even with a VM would requires a religion change.
Experience (I have tried) prove to be out of reach.

Secondly, method required to work with OBS make a few things fairly
complex for embedded developers. In particular, when you port MeeGo on a
new special HW, you first need to create a new Kernel config and that
with OCS is not simple. Our goal is to make that type of things easy but
enabling them to use the method that they know (work in the chroot).

If a local OBS would be used, then the full build environment could be
part of the VM appliance and the build process would be executed in
local workstation. All required configurations, repository settings
and such would be included to the project by local system admin.
Perhaps all developer tools [editors etc], which are required in that
project, should be included in appliance which would allow really
"standard desktop implmentation"; if such is needed. After
development cycle, the cleanup of development desktop would require
just the deletion of local VM appliance. All other VM benefits would
also be included, such as distributed build process, platform
independent development, load balancing etc.


To be honest, as the first implementation of light OBS will be done on
OpenSUSE only (simpler). We might use a VM to deliver the version 1.0.
But still we need a tool to help embedded people to create patches in RPM.
But I agree that your idea to develop it in a first step with a full OBS
running as a local appliance in a VM in lieu of the GostOBS module
proposed is a good short cut for an early phase1. I am a bit afraid by
the complexity of delivering the VM as installation is difficult to
fully automate but the idea is interesting and might simplify the
project maintenance.

I will push Ronan (project maintainer) to get a look at that idea.

Thanks.

-- Dominig

06/19/2011 09:07 PM, David Greaves kirjoitti:
On 14/06/11 13:44, Dominig ar Foll (Intel OTC) wrote:
I had a brief look and I did not understand if you plan to use just
the "build" script directly or if you are about to invent something
else.
For the build part we plan to reuse the build script. No need to
reinvent the wheel.

I'm also looking at making OBS fit more easily with the developer
workflow in a sizeable MeeGo/OBS project in Teleca/LGE. (And by
developer I don't mean just the elite code hackers who inhabit lkml etc;
I need to cover junior devs too).


Could the developers in this project use "standard" environment, which
would actually exist as a virtual desktop, or virtual appliance? Would
it be plausible in resource wise?

My initial thoughts had been to prepare something like:
* osc chroot : to prepare a clean build area, probably with gdb etc too
* mount -bind /path/to/vcs-managed-src /path/inside/chroot/src
* developer hacks and saves in their 'desktop' environment
* osc 'rebuild' : runs rpmbuild with hacks but without cleaning chroot.
(since I did something like this a couple of years ago)

Issues include:
* support multiple packages in one mega-chroot?
* updating chroot efficiently?
* not rm -rf'ing a build chroot with a mount -bind .git tree (!)
* create a project or team specific meta-package which depends on
various useful rpms to allow osc build -x my_dev_env to be easy.


How much of this could be achieved with implementing more modular
installation setup of the packages or just in coding process of
developers? [this was not a real question, just thinkin aloud :]

I really haven't had time to properly analyse my requirements or the
possible solutions so this is very much a hand-waving and a "me too"
email.

I will say that I'm in favour of a solution using a real OBS - an
appliance VM would be fine.

The build script can be used complete standalone at least or embeeded
in osc
local builds or obs service side builds.
Yes osc can do that. What osc does not do easily is to re-extract the
change done in the chroot to create a patch to apply to the original
package.

This seems too hard to support in any meaningful general case. How do I
know if the Makefile that just appeared is because I made it or because
I ran autoconf?
OK, you could just support modifications but then you risk losing real
work in new files.

I was going to allow access to git inside the chroot and probably
looking at some git/quilt workflow for those who like the patch
approach. There is a very nice policy in a supporting tool in debian's
git-buildpackage which I'm in the process of 'porting' to rpm over the
next week (I hope).
see : https://honk.sigxcpu.org/piki/development/debian_packages_in_git/

Some plugin like "osc trialbuild" would use that policy to extract
patches from the git tree and update the spec; send them to the OBS and
build there.

In embedded we are targeting a developer population which works in the
chroot directly.

Agreed. One of my first patches to OBS was to make the UID of the chroot
user match the real user so you could use the 'desktop' editor against
the chroot path.

Or would it be find to do a local build via "osc build" in chroot
using the
resources from a remote OBS server ?
If you look at the UI in the Spec you will notice that we are
planing to
allow the dual mode (local or remote OBS repo as reference).
Our goal is to help embedded project to move to OBS.

Whilst this isn't precisely my goal, I know that a reasonably large
subset of devs (especially in the hardware adaptation layers) will have
come from that area so I'm also interested in making their environment
seamless as they move into a production use of the OBS in their
integration workflow.

Some part OBS light will be created as plug-ins to osc (e.g. the patch
creation tool) and that could be of a general value for all OBS users.

I wonder if we can start by providing some useful wrappers, workflows
and the like around osc and the current system?

NB. If there's not much interest on the obs list then I'm happy to
continue discussions on the meego-distribution-tools list.

David



If this sounds even slightly interesting, I can explain more deeper.
If this has been said earlier allready, I apoplogize, but I haven't
noticed that.

yours,

Tommi


--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >