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
