[MeeGo-dev] Specification for OBS light project concept
Kok, Auke-jan H
auke-jan.h.kok at intel.com
Fri Jul 1 11:49:53 PDT 2011
On Fri, Jul 1, 2011 at 11:26 AM, Andy Ross <andy at plausible.org> wrote:
> On 07/01/2011 10:59 AM, Kok, Auke-jan H wrote:
>> I think Ryan is spot on. Until you get out of the hack-n-slash
>> phase, your main development model should just be git, and ignore
> Yeah, but I'm with Shane on this. There's a big gap right now between
> "I have a sandbox build with a fix and a patch" and "I have a working
> package in OBS". And that gap is filled with traps, all of which
> involve round trips to a known-finicky web app:
> + Have to remember the spectacle syntax again.
you don't have to use spectacle.
> + Patch collides with others: have to muck with ordering and respin.
this is what devel projects are for: a sandbox where you're reasonably
protected from changes in certain areas.
all my devel projects build against MeeGo-1.2, Trunk, and
Trunk:Testing. If Trunk and Trunk:Testing cause me to frown and spend
too much time fixing up stuff, I just work against MeeGo-1.2 for a
Or even MeeGo-1.1.
> + Oops, forgot to update changes file (or just typo the date, builds
> kick back if the dates aren't monotonic)
irrelevant if you work in a devel project: You can violate all merge
rules until you actually submit to Trunk:Testing. But at that point,
you better fix your bad hack-n-slash packaging ;)
> + Oops, built in a Trunk project branch when I should have branched
> + It's built, but won't install cleanly from the resulting repo
> because the OBS build numbers are lower than the real version (quick
> hack is to update a file a dozen times here), and it's something
> like qt or libmeegotouch with frightening interpackage dependencies.
Seems like a legitimate concern where OBS needs to be fixed. Please
file a bugreport?
> + Get everything ready, and just to annoy you OBS asks for a *third*
> commit message (one in the patch, one in the .changes file, and a
> third for the SR). Look up the bug number one last time...
If you have a proper .changes file, you can leave this entirely empty.
So, should not be an issue.
> Add to that the fact that OBS projects are sometimes heavily patched,
> and there's no straightforward path to turn an OBS project into a
> buildable sandbox tree. The adaptation kernels and qt are really bad
> in this respect. You can't meaningfully work with upstream code at
> all for some things.
Blame the kernel/Qt maintainer, not OBS? Performance is an issue,
obviously, this probably needs to be a bugzilla.
> And on top of it all, setting up OBS itself is really non-trivial. I
> think something like this tool would be very useful, honestly, though
> I think it's likely to be a ton of work to maintain.
setting up OBS or osc?
I just set up osc at home last week in 3 minutes on a totally
unsupported distro (not even a .deb/.rpm distro) and I was able to
Setting up OBS is something we have a team of people for to do this
for projects. And, it's not easy, and we should see if we can improve
it somehow. That does not warrant an OBS fork imo...
More information about the MeeGo-dev