diff options
| author | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
|---|---|---|
| committer | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
| commit | 1be510f9529cb082f802408b472a77d074b394c0 (patch) | |
| tree | b175f9d5fcb107576dabc768e7bd04d4a3e491a0 /zarb-ml/mageia-dev/2012-September/018673.html | |
| parent | fa5098cf210b23ab4f419913e28af7b1b07dafb2 (diff) | |
| download | archives-master.tar archives-master.tar.gz archives-master.tar.bz2 archives-master.tar.xz archives-master.zip | |
Diffstat (limited to 'zarb-ml/mageia-dev/2012-September/018673.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2012-September/018673.html | 231 |
1 files changed, 231 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-September/018673.html b/zarb-ml/mageia-dev/2012-September/018673.html new file mode 100644 index 000000000..2a1f507f3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-September/018673.html @@ -0,0 +1,231 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] unity on mageia + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20unity%20on%20mageia&In-Reply-To=%3CCAPVS_ccTw%3D2Rv6s6fJRit%3Dr6XJZum12ebxO82F%2Bk2xSTAAxEMA%40mail.gmail.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="018672.html"> + <LINK REL="Next" HREF="018678.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] unity on mageia</H1> + <B>Damian Ivanov</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20unity%20on%20mageia&In-Reply-To=%3CCAPVS_ccTw%3D2Rv6s6fJRit%3Dr6XJZum12ebxO82F%2Bk2xSTAAxEMA%40mail.gmail.com%3E" + TITLE="[Mageia-dev] unity on mageia">damianatorrpm at gmail.com + </A><BR> + <I>Fri Sep 14 14:03:46 CEST 2012</I> + <P><UL> + <LI>Previous message: <A HREF="018672.html">[Mageia-dev] unity on mageia +</A></li> + <LI>Next message: <A HREF="018678.html">[Mageia-dev] unity on mageia +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#18673">[ date ]</a> + <a href="thread.html#18673">[ thread ]</a> + <a href="subject.html#18673">[ subject ]</a> + <a href="author.html#18673">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Hi Colin, + +Thanks for you're answer! + +><i> The "Here is my PPA where I do x, y and z" style approach to software +</I>><i> repositories is always one we've deliberately avoided. It's creates +</I>><i> significant problems for our (relatively) small teams when doing QA and +</I>><i> addressing bug reports. +</I>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). + +><i> This is Canonical's choice +</I>><i> when they designed things this way. I'd rather see more upstream +</I>><i> collaboration, and I'd personally want Mageia to encourage that general +</I>><i> principle, I don't like divergence and I favour collaboration. +</I>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. + +><i> 3. Ignoring the above points and thinking more practically, would you +</I>><i> propose to use the same specs for Fedora, OpenSuse and Mageia for the +</I>><i> packages or would you use separate ones? If they are the same, then I suspect this would +</I>><i> cause even more issues as the distros obviously diverge in their +</I>><i> packaging structure. +</I>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 ( +<A HREF="https://build.opensuse.org/package/view_file?file=obsdiff&package=0_TODOS_SCRIPTS_ETC&project=GNOME%3AAyatana">https://build.opensuse.org/package/view_file?file=obsdiff&package=0_TODOS_SCRIPTS_ETC&project=GNOME%3AAyatana</A> +) 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. + +><i> 4. How do you handle automatic rebuilds when a package changes? e.g. +</I>><i> when we change our official gtk, I presume you would want to +</I>><i> automatically rebuild yours too? Also what if lower level things change, +</I>><i> e.g. automated provides/requires extraction stuff provided at a lower +</I>><i> level. I presume all this stuff "just works" in OBS? +</I>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). + +><i> 5. Regarding using OBS generally for Mageia, I would not personally be +</I>><i> against it in principle, but there are lots and lots of barriers there. +</I>><i> We do already have a working build infrastructure and we can control it +</I>><i> and have experience of fixing, tweaking it etc. We know it's quirks. +</I>><i> With OBS it would be like starting again. That's not to say it wouldn't +</I>><i> be the "right choice", but it could very easily not be the "right choice +</I>><i> right now". It would take the primary sysadmins to be really +</I>><i> enthusiastic and keen on any transition and know exactly what benefits +</I>><i> it would bring us. Although I can't speak for everyone, I just don't +</I>><i> think there is enough in the way of resources right now for that to be +</I>><i> the case. +</I>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: <A HREF="http://blog.mandriva.com/en/2011/07/19/we-start-collecting-wishes-for-new-build-system/">http://blog.mandriva.com/en/2011/07/19/we-start-collecting-wishes-for-new-build-system/</A> +) + +><i> 6. While I'm sure the web interface is nice, I presume it must link +</I>><i> directly to a RCS in the background? e.g. we'd need it to hook into our +</I>><i> subversion system right now. AFAIUI OBS had a some crazy custom RCS +</I>><i> behind it. Is this now more generic? Can it hook up to subversion and/or +</I>><i> git these days, how would it deal with user authentication? +</I>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 <A HREF="OBS://Mageia">OBS://Mageia</A> 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 +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="018672.html">[Mageia-dev] unity on mageia +</A></li> + <LI>Next message: <A HREF="018678.html">[Mageia-dev] unity on mageia +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#18673">[ date ]</a> + <a href="thread.html#18673">[ thread ]</a> + <a href="subject.html#18673">[ subject ]</a> + <a href="author.html#18673">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |