[Mageia-dev] unity on mageia

Fri Sep 14 14:03:46 CEST 2012

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
+