[Mageia-dev] unity on mageia

[Damian Ivanov]

Hi Colin,

Thanks for you're answer!

> The "Here is my PPA where I do x, y and z" style approach to software
> repositories is always one we've deliberately avoided. It's creates
> significant problems for our (relatively) small teams when doing QA and
> addressing bug reports.
Agreed, I'm quite sure 90% of users use additional repos anyway, in
Mageia this percentage is
most likely lower than on Fedora and openSUSE (where you need 3rd
party repos for mp3 and binary drivers)
due to included multimedia, nvidia/ati stuff in nonfree and tainted,
still Mageia users will want to install chrome, skype repos. In future
they may want to have a steam repo, if Valve is cheerful. So one
option would be to have unity repo as a 3rd party repo, where I
understand it would be even worse for some people since it is
tinkering with gtk2,gtk3 and few other packages. The other thing
getting it in main Mageia repo would be much easier in OBS (will
explain below).

> This is Canonical's choice
> when they designed things this way. I'd rather see more upstream
> collaboration, and I'd personally want Mageia to encourage that general
> principle,  I don't like divergence and I favour collaboration.
I favour collaboration too, but the Canoncial actually tried there
best for upstream collaboration.
I reviewed some of the patches in gtk, gnome-control-center etc. Most
have filed bugs upstream,
e.g
1. bug gnome-control-center to have an option in power to set an
action for what happens when closing laptop lid
including Canoncials patch => closed won't fix => irritating user with
too much options
2. gtk's appmenu => closed won't fix because Gmenu exists and gtk is
designed for gnome-shell...,
on Ubuntu both things work appmenu and Gmenu, on vanilla gtk only Gmenu,

It's just people "upstream" even denying things that are optional.
Actually Canoncials did the gtk2 and gtk3
packages can be looked like a fork, but they choose to not have there
own git/svn/bzr gtk3-ubuntu,
but to patch the vanilla sources so it is easier to stay close to
upstream and not going in different direction,
where the code base would be un-revertable scattered across different
projects (so IMO they did the community a favor).
Would it be acceptable to have in the main repos gtk3 and gtk3-ubuntu
(both providing gtk3, but conflicting)?
The other thing I thought of, but I am not sure if we can actually do
this, is having %dir/gtk3 and dir %dir/gtk3-ubuntu
and libgtk3, libgtk3-ubuntu installed at the same time and being a
choice by alternative chooser.

> 3. Ignoring the above points and thinking more practically, would you
> propose to use the same specs for Fedora, OpenSuse and Mageia for the
> packages or would you use separate ones? If they are the same, then I suspect this would
> cause even more issues as the distros obviously diverge in their
> packaging structure.
Yes and no. Lot of the packages could be even with one spec file, the
naming and dir structures
are only a problem for few packages where distro specific rules
differ, the most diff we actually have
are the build time macros. In most packages that are not half-forks
(e.g gtk is a half-fork) only 2-3 lines in the whole
spec file differs. For these packages we have the following OBS strucutre:
$Package (folder)
==>sources.tar.gz
===> a) %name-openSUSE_12.2.spec (or only %name.spec)
===> b) %name-Fedora_17.spec
I made a script that keeps track of each packages spec's diff and on
a whole repo's diff (
https://build.opensuse.org/package/view_file?file=obsdiff&package=0_TODOS_SCRIPTS_ETC&project=GNOME%3AAyatana
) and we are trying to eliminate these few bits by collaborating with
distros to get closer their macros. The Requires section is quite well
working
with pkgconfig.

> 4. How do you handle automatic rebuilds when a package changes? e.g.
> when we change our official gtk, I presume you would want to
> automatically rebuild yours too? Also what if lower level things change,
> e.g. automated provides/requires extraction stuff provided at a lower
> level. I presume all this stuff "just works" in OBS?
Ok so here we come to our half-fork packages like gtk. Yes this just
works on OBS for OBS based repos/distros/projects.
We can branch openSUSE/gtk3 to Ayatana/gtk3 and we can optionally
choose merge future changes from upstream, making it possible
Ayatana/gtk3 to be just the openSUSE/gtk3 with Ayatana patches, if
openSUSE/gtk3 adds a gtk3-omg-crash.patch our package will be rebuild
too with our patches and this new patch. For Fedora we need to monitor
it on our own since Fedora is not using OBS (partially with scripts
notifying us).

> 5. Regarding using OBS generally for Mageia, I would not personally be
> against it in principle, but there are lots and lots of barriers there.
> We do already have a working build infrastructure and we can control it
> and have experience of fixing, tweaking it etc. We know it's quirks.
> With OBS it would be like starting again. That's not to say it wouldn't
> be the "right choice", but it could very easily not be the "right choice
> right now". It would take the primary sysadmins to be really
> enthusiastic and keen on any transition and know exactly what benefits
> it would bring us. Although I can't speak for everyone, I just don't
> think there is enough in the way of resources right now for that to be
> the case.
Well what benefits would it bring.
- Connection of instances, build.mageia.org can link/aggregate to
packages at build.opensuse.org
- Can autofetch from git/svn/bzr
- Automatic rebuild
- Webinterface
- OBS is the most widely-used build system
(openSUSE, SLES, Meego, Dell Community Repository, United States
Postal Service, various universities and others)

-It will be lot easier for packagers to maintain packages for various
distributions (even when they are in the main
  repo of these distribution).
     ==> Upload new version for package ==> Change in spec's ==>
Create one push request per distro

Sure there is "never change a running system".
What we could do is, for a soft beginning:
1. get OBS build Mageia .rpm's
2. get OBS run on Mageia as host (it is running already on centOS, so
it is portable)
3. use in parallel Mageias build structure and OBS (OBS can rsync
Mageia source packages and rebuild them)
   for a soft transition.

PS: and well I would help, Adrian Schroeter, the man who does the most
things for OBS may offer help too, as he offered it to Mandriva (see
comments: http://blog.mandriva.com/en/2011/07/19/we-start-collecting-wishes-for-new-build-system/
)

> 6. While I'm sure the web interface is nice, I presume it must link
> directly to a RCS in the background? e.g. we'd need it to hook into our
> subversion system right now. AFAIUI OBS had a some crazy custom RCS
> behind it. Is this now more generic? Can it hook up to subversion and/or
> git these days, how would it deal with user authentication?
OBS has a non-git/svn RCS (I don't think the default would change, but
may a backend is possible).
OBS's RCS works great with user authentication. Every project e.g on
the obs instance build.mageia.org each project can have set different
users set. e.g OBS://Mageia has 2 maintainers (only these are allowed
to accept request and change the sources and delete or create new
packages), 5 Bugowner	10 Reviewer 10 Downloaders	 5 Readers. It also
support groups rather than users. Revision control is great, one
command or 4 clicks in the WebUI to rollback to any revision with also
the possibility to see the diff of each to each repository in the
webui and directly browse sources of old revisions)

Cheers,
Damian