[gentoo-dev] Re: Portage: missing pieces
Kevin F. Quinn wrote: The expectation here is that when a new version of gcc is stabilized, that users will upgrade to that in a reasonable amount of time, and use that (by selecting it with gcc-config) for compiling all new updates. FYI, gcc-3.4.4-r1 was stabilized on 2-Dec-2005, and the current stable is 3.4.6-r1 since May 29th. I don't see how that information is conveyed to the user. It's conveyed by the fact that when updating, you see a new compiler version being installed. If you have done a world update, you already have the later compilers installed. No, that's not true. It's not conveyed at all. It might install a new GCC, but it doesn't switch to it. It doesn't tell the user to switch to it, either. As has been explained before, as far as the gcc ebuilds are concerned their job is finished when the new compiler version is installed. It is up to the user to decide to change their system compiler. You seem to have missed the issue. Yes, ok. That's a bad alternative. Thus it seems that there's no appropriate mechanism to handle new GCC versions in Portage, which again makes sense wrt. the complaints. Portage and the ebuilds handle it fine. Same. All that needs to happen is for users to accept the advice to read the gcc upgrading guide when they trip over problems that arise from issues with gcc versions. There's no advice, instead Portage crashes during a system update. Nothing? I find it unacceptable that the bug is marked INVALID when it clearly describes a relevant issue. Don't take the bug marking as a personal attack I don't, it's not my bug ;-). it's a marking for devs to understand what was the impact of the bug. It's marked INVALID, while the issue is clearly valid. Focus on the advice given, which from what I can see was succinct and correct. It shouldn't even be _necessary_ to create bugs and receive advice from a living, breathing human being just to perform a system update. As far as I can tell, the complaints are about Portage being unable to handle GCC upgrades gracefully for end users. What exactly do you expect to happen? GCC updates don't switch major versions automatically, because in general it means changing ABI which means rebuilding everything. Ah, that's a good question. I think the proper reaction from Portage would be (both): a) Alert the user that the newest version of package XYZ cannot be merged because it needs a newer compiler than the currently selected one. b) Skip package XYZ, but continue updating the rest of the system. Package XYZ could also block the update, that would be OK. Again, this is not a personal attack but information for devs to understand whether different work is needed for the different bugs. Noone has mentioned personal attacks, so drop that train of thought. You misread my point. I was trying to say that bugs describing problems (with fx. Portage) in abstract will often get closed as a duplicate of a bug where someone has experienced a particular incarnation of the larger problem described. That's a good way to make sure that relevant end user issues never come into contact with the devs, which I'm sure is not what the devs want. I suppose portage could be enhanced to have a is_gcc_version_supported() check, but I'm not sure how useful that would be. If that would enable ebuild maintainers to flag xine as requiring 3.4 for compilation, then that would definitely solve the issue described in the bug. I'd say that's _very useful_ to the end user. The problem with having the xine ebuild check gcc version and aborting if a certain version is found active, I don't think anyone would implement it that way, since that's braindead ;-). Instead of checking a particular version, checking for a minimum version would be the default available functionality. is that if the gcc version is modified in the future such that xine would then build with it, that handling would have to come out again. In the (hysterically abstract) situation where someone revisits an old version of GCC and adds GCC-4 features, nothing would break. Users would still be told to upgrade to a newer version, and all would be well, despite the fact that the old GCC with the backported feature could now theoretically be used. (But it's just trolling anyway, you're really describing a non-issue, IMHO.) Another way of looking at it, is that there are a lot of people out there who are coping just fine with GCC upgrades as they are currently managed. Uh. What's your point? That you're one of those people who hates change just because it's change, or do you have something more relevant to say that I'm not catching? See https://bugs.gentoo.org/page.cgi?id=fields.html - as far as devs are concerned, The problem described is not a bug so INVALID is the correct resolution marking. Not a bug does not translate to Not an issue. You're practicing an extremely narrow view of what's a bug, and
[gentoo-dev] Re: Portage: missing pieces
Richard Fish wrote: Having dozens (hundreds? all?) ebuilds check for a minimum version Probably just the ebuilds that happen to use new GCC features before the mass of the general public has changed to that version. But yes, a minimum version constraint could theoretically end up in a lot of packages. of gcc doesn't seem very effecient. I can't see why it would not be efficient? I don't think the issue is as simple as either having xine-lib put out a warning about a particular gcc version, as that doesn't work in the general case. Obviously any solution implemented should work for all ebuilds, not just xine-lib. And putting the checks in portage doesn't seem to work very well either. I fail to see how a test in the ebuild for the active GCC compiler version wouldn't work? The system as it is now actually seems to work about right... the vast majority of stable users upgrade to new versions of gcc as they come out Really? How do you gather? I'd think that most users hadn't even run into this problem (yet), because many source code maintainers strive to be able to compile with as old a version of GCC as possible.. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
Jakub Moc wrote: Sigh. Because it would break your system! You really need to research better if you insist on beating a dead horse over and over again. Kindly read the toolchain.eclass: You're misreading me. I was merely counter-arguing Kevin, who said that Portage provides plenty of information to the end user about GCC switches being necessary. I was not trying to convince anyone to make Portage switch GCC version automatically. That would probably be rather insane. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
Molle Bestefich wrote: The current situation is very annoying for users that update often, and also makes Portage mostly unusable for automatic server upgrades After unmerging mono-tools so Portage could finally run a whole update, it stopped halfway through because of this bug: http://bugs.gentoo.org/show_bug.cgi?id=132122 I noticed that several users have commented with a relevant complaint: GCC-4.x is required by the ebuild, but no information is ever conveyed to the end user about this fact. The ebuild does not have a dependency on GCC-4.x. Try reading the bug - users are basically being shoved off with an arrogant silence and a stamp on their forehead saying INVALID. Nothing personal against Jakub Moc who probably has a lot to do, but the handling of relevant issues raised in the bugzilla is just unacceptable. What's the state of Portage and Gentoo in general? Is there not enough hands to do a proper job? Or is it just that none of the devs see what's wrong because bugs are wrongly being closed marked INVALID such as the above when they're in fact not? -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] helping out - how?
I'd like to take a stab at maintainership (or at least fixing) an unmaintained ebuild. What versioning system do you guys use (CVS?), and what's the URL for checking out ebuilds? (I was thinking that I'd conjure up a patch and submit it here so someone with commit access can put it in.) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
Jakub Moc wrote: Try reading the bug - users are basically being shoved off with an arrogant silence and a stamp on their forehead saying INVALID. Nothing personal against Jakub Moc who probably has a lot to do, but the handling of relevant issues raised in the bugzilla is just unacceptable. Dependency on a particular gcc version will solve exactly nothing. Having that version installed doesn't mean you are really *using* it. You won't be automagically switched to 3.4.x when upgrading from 3.3.x, you won't be automatically switched to gcc 4.x when upgrading from 3.4.x Yes ok. So the user has to both merge the new version, and switch to it. Either way, the end user is not getting told what should be done, instead Portage just breaks, which is exactly what all the complaints are about. How about the you finally upgrade your outdated gcc, as asked over and over again? gcc-3.3.x is dead, unsupported upstream, we won't be fixing any bugs there. Hard to understand? Apparently, I guess... I've never been told so, I have no clue what you are talking about. Thanks for your rant. What kind of reply do you expect to get from such crap? Thanks for being an asshole? -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: helping out - how?
Ioannis Aslanidis wrote: You'd rather fill in a bug report and submit the patch in the bug. Not in this list, definitely. Oh, ok. Never mind then, I fear I'd be spending way too much time fighting with Jakub trying to get the ebuild in the tree. I'll just drop it. (Nothing personal, I just don't think it would work out, heh.) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
Richard Fish wrote: The expectation here is that when a new version of gcc is stabilized, that users will upgrade to that in a reasonable amount of time, and use that (by selecting it with gcc-config) for compiling all new updates. FYI, gcc-3.4.4-r1 was stabilized on 2-Dec-2005, and the current stable is 3.4.6-r1 since May 29th. I don't see how that information is conveyed to the user. Portage shouts about upgrading to a new profile from time to time, but it never tells anyone to upgrade GCC. Perhaps it should, if that's what the devs expect people to do. The devs can *not* be expected to verify that all software in portage builds with all versions of gcc in portage. Of course not. The alternative here is that old versions of gcc disappear from portage, but that causes a problem for those who need those versions for some reason, such as compiling non-gentoo software. Yes, ok. That's a bad alternative. Thus it seems that there's no appropriate mechanism to handle new GCC versions in Portage, which again makes sense wrt. the complaints. Nothing personal against Jakub Moc who probably has a lot to do, but the handling of relevant issues raised in the bugzilla is just unacceptable. What, exactly, do you find unacceptable in Your gcc version is outdated and unsupported? Nothing? I find it unacceptable that the bug is marked INVALID when it clearly describes a relevant issue. As far as I can tell, the complaints are about Portage being unable to handle GCC upgrades gracefully for end users. You could perhaps argue that the issue started out as why do I get this error message and ended up being why doesn't Portage handle GCC upgrades gracefully, which is of course a slightly different thing. But it should be clear to anyone reading the bug what the real issue is. I'm even willing to bet that if I create a new bug describing the Portage issue, with no mention of the specific xine ebuild, it will get closed as a duplicate of this bug anyway. I've got case studies proving that this is what happens, heh. I suppose portage could be enhanced to have a is_gcc_version_supported() check, but I'm not sure how useful that would be. If that would enable ebuild maintainers to flag xine as requiring 3.4 for compilation, then that would definitely solve the issue described in the bug. I'd say that's _very useful_ to the end user. You could argue that only a couple of people has spent the time to create a bugzilla login and lodge a complaint in the bug, but there's probably more out there. We can count the duplicates in a couple of months and see ;-). And as newer GCC features are used throughout, the situation will probably happen more in the future. What's the state of Portage and Gentoo in general? Is there not enough hands to do a proper job? Or is it just that none of the devs see what's wrong because bugs are wrongly being closed marked INVALID such as the above when they're in fact not? If you want to test compiling every version of every package in portage with all 21 versions (16 if you assume all -rX versions are compatible, or /only 9/ if you only consider stable x86 versions) of gcc that are currently in portage, and submit patches when things fail, go ahead. That won't be necessary. Things mostly works, and when they don't, users file a bug like the aforementioned one, which should result in that particular ebuild getting fixed, instead of the bug being marked INVALID. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: helping out - how?
What versioning system do you guys use (CVS?), and what's the URL for checking out ebuilds? bugs.gentoo.org is where this kind of work is done. There's already an existing but unmaintained ebuild. That's what I wanted to check out, so I could modify it and submit a diff -u. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
Richard Fish writes: Unfortunately the Gentoo dev's have taken the rather unusual step of _breaking the tree_ due to a security problem. Thanks for the info. I would really wish that there was some mechanism in place to make sure that the tree was never broken. The current situation is very annoying for users that update often, and also makes Portage mostly unusable for automatic server upgrades :-(. 1. Unmerge both mono-tools and gecko-sharp. That did the trick. I'll have to remerge it later when/if the tree gets fixed... Thanks! (I see now that it was just me that didn't understand how to use --tree, which makes much of this conversation off-topic... Sorry about that!) [1] http://bugs.gentoo.org/show_bug.cgi?id=137665 I'm thinking that a Subversion pre-commit hook to secure integrity of the Portage tree would be cool. The changes listed in the bug above would have to be committed atomically, or it wouldn't get through the integrity check. Perhaps there could be a staging area in the form of a branch where the hypothetical integrity checker wouldn't run. Ho hum, wishful thinking. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
Pierre Guinoiseau writes: pam-login is now included in shadow, you no longer need to emerge it. Thanks, that's what I needed to know. I had done an emerge -D world, and suddenly I couldn't turn on the PC. I later found out that /sbin/login had been removed. Richard Fish writes: USE=mono emerge -Devp evolution No mozilla comes in. So evolution does not depend on mozilla, at least not directly. Ok. Same picture here. (Above command pulls in 402 other packages though... caramba) In fact, in the current portage tree, mozilla is going away, and being replaced by seamonkey. Very few (and hard masked) packages like gecko-sdk still depend on mozilla. So what you should eventually end up with is no mozilla but seamonkey. Thanks for the info! Are you using an portage overlay? If so, what is in it? No. No idea what that is. Sounds interesting, though. When was the last time you did an emerge --sync? Yesterday. It changed things a bit since last time (month ago?), but it still wants to merge mozilla. Only now it's mono-tools (or rather gecko-sharp) that wants it, Evolution is out of the picture: [nomerge ] dev-util/mono-tools-1.1.11 [ebuild N] dev-dotnet/gecko-sharp-0.6 [nomerge ] www-client/mozilla-1.7.13 Also, the full output of emerge -Duvpt world Attached. Note that I got rid of the Xorg-6.9 blockers by merging virtual/xft-7.0. Doesn't make any sense to me at all, explanations sought for :-). These are the packages that would be merged, in reverse order: Calculating world dependencies . . !!! Packages for the following atoms are either all !!! masked or don't exist: media-tv/atitvout ... done! [blocks B ] www-client/seamonkey (is blocking www-client/mozilla-1.7.13) [blocks B ] www-client/mozilla (is blocking www-client/seamonkey-1.0.2) [ebuild U ] kde-base/kwalletmanager-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 2,910 kB [ebuild U ] sys-fs/device-mapper-1.02.07 [1.02.02] 902 kB [ebuild U ] kde-base/kdebase-meta-3.5.3 [3.5.2] 0 kB [ebuild U ] kde-base/konsole-3.5.3-r1 [3.5.2-r1] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 6 kB [ebuild U ] kde-base/ksysguard-3.5.3-r1 [3.5.2-r2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% -lm_sensors -zeroconf 0 kB [ebuild U ] kde-base/knetattach-3.5.3 [3.5.1] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kdeprint-3.5.3 [3.5.2] USE=cups kde xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kghostview-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 7,129 kB [ebuild U ] kde-base/ktip-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kate-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kscreensaver-3.5.3 [3.5.1] USE=opengl xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kmenuedit-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kpager-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/drkonqi-3.5.3-r1 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kappfinder-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kxkb-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 5 kB [ebuild U ] kde-base/klipper-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [nomerge ] app-cdr/k3b-0.12.14 USE=alsa encode ffmpeg flac kde mp3 sndfile* vorbis xinerama -arts* -css -debug -dvdr -hal -musepack -musicbrainz -vcd [ebuild U ] app-cdr/cdrdao-1.2.1-r1 [1.2.1] USE=encode gnome -debug -pccts 0 kB [nomerge ] dev-cpp/gtkmm-2.8.1 USE=-debug [ebuild U ]dev-cpp/glibmm-2.8.4 [2.8.1] USE=doc* -debug 1,977 kB [ebuild U ] kde-base/konq-plugins-3.5.3 [3.5.2-r1] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 1,607 kB [ebuild U ] kde-base/konqueror-3.5.3 [3.5.2] USE=java xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] kde-base/kfind-3.5.3 [3.5.2] USE=xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% 0 kB [ebuild U ] dev-libs/openobex-1.2-r1 [1.0.1] USE=bluetooth% -debug% -irda% -syslog% -usb% 333 kB [nomerge ] media-video/konverter-0.92_beta1 USE=xinerama -arts* -debug [ebuild U ] media-libs/xine-lib-1.1.2_pre20060328-r9 [1.1.2_pre20060328-r1] USE=X aac alsa asf directfb esd* fbcon ffmpeg flac gnome ipv6 mad opengl oss sdl theora vorbis win32codecs xinerama xv -a52 -aalib -arts* -debug -dts -dvd -dxr3
[gentoo-dev] Portage: missing pieces
I think a piece might be missing from Portage. I'll depict my workflow as an example. I'm preparing to upgrade: # emerge --sync # emerge -Dp world [blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-libs/libXinerama-1.0.1) [blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-libs/libXi-1.0.1) [blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-libs/libXrandr-1.1.1) [blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-proto/randrproto-1.1.2) [blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-misc/makedepend-1.0.0) [blocks B ] =x11-base/xorg-x11-6.9 (is blocking media-libs/mesa-6.5-r3) [blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-libs/libdrm-2.0.1) [blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-proto/xf86vidmodeproto-2.2.2) [blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-proto/glproto-1.4.7) [blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-proto/xf86driproto-2.0.3) ... etc, lots of blockers ... Ok, let's try and find why it wants to downgrade to xorg-x11-6.9: # equery d xorg-x11-6.9 [ Searching for packages depending on xorg-x11-6.9... ] none found # Ok, no reason, apparently. Maybe it's already merged then? # emerge -C xorg-x11-6.9 --- Couldn't find 'xorg-x11-6.9' to unmerge. Nope. Now I'm getting uncertain. Don't I have xorg-x11 at all? # emerge -C xorg-x11 x11-base/xorg-x11 selected: 7.0-r1 protected: none omitted: none 'Selected' packages are slated for removal. 'Protected' and 'omitted' packages will not be removed. Waiting 5 seconds before starting... (Control-C to abort)... Unmerging in: 5 4 3 CTRL-C Exiting on signal 2 Whoops. Yep, it's there. Ok, so status is that I have xorg-x11-7.0, I don't have 6.9, no packages actually wants xorg-x11-6.9, but whenever I use emerge -D world, Portage sees it as a blocker anyway. Is there a piece missing in this puzzle, in particular the one that will tell me why on earth Portage thinks version 6.9 is a blocker? Or is the piece in place but I'm not looking hard enough? -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
Molle Bestefich wrote: I think a piece might be missing from Portage. I'll depict my workflow as an example. Same thing with a package called 'seamonkey': # emerge -Dpt world These are the packages that would be merged, in reverse order: Calculating world dependencies... done! [blocks B ] www-client/seamonkey (is blocking www-client/mozilla-1.7.13) [blocks B ] =sys-apps/shadow-4.0.14-r2 (is blocking sys-apps/pam-login-4.0.14) [blocks B ] sys-apps/pam-login (is blocking sys-apps/shadow-4.0.15-r2) ... etc ... # emerge --unmerge seamonkey --- Couldn't find 'seamonkey' to unmerge. No packages selected for removal by unmerge. # equery d seamonkey [ Searching for packages depending on seamonkey... ] # Nobody wants a seamonkey, and I haven't got one already, but Portage wants to smuggle one in anyway if I tell it to upgrade world. Where's the piece that can tell me why Portage wants to do so? (Alternatively, what's the manual process to find out?) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
Dont snip. The relevant part comes *after* the blocks lines. Aah. I get it. Thanks. Sorry for the noise. www-client/seamonkey (is blocking www-client/mozilla-1.7.13) Also, you are mis-interpreting the blocks lines. The correct reading of X (is blocking Y) is that you have (or should have) X installed, and now portage wants to install Y instead. Usually this is because Y supercedes the functionality that used to be provided by X, and in almost all cases, the right thing to do is to unmerge X and merge Y. Evolution depends on Mozilla and Mono depends on SeaMonkey. Mono is the newer (actively developed... sort of) component, also, from what I've heard, SeaMonkey is based on a vastly newer version of Gecko. So I'm not sure how that fits with the above. Anyway, I tried unmerging SeaMonkey and merging Mozilla, which went fine. Doesn't help any with the blocker status, though. So I'm stuck here. Is it impossible to have Mono and Evolution installed at the same time? (Same story with OpenSSH and pam-login. OpenSSH wants shadow, and pam-login refuses to merge alongside shadow. I want both pam-login and OpenSSH, but seems like I'll have to choose, right?) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: backups: remove Portage cruft?
[snip - Mike, Robin, Joerg, Alec and Marius were kind enough to answer my questions...] Thanks guys! That should shave a couple of hours off each nightly backup.. :-)) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Sharing portage?
Hi Follow-up question to the backup thingy. Is there an easy way to share Portage's database between multiple virtual machines? Optimally, I would emerge --sync and the results would land in a filesystem that I'd share between VMs, so I don't have to do emerge --sync in each and all of them. The filesystem could perhaps be readonly to the virtual machines, except for the one doing the --sync of course. (Currently, I run emerge --sync in all virtual machines.) Thanks! -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] backups: remove Portage cruft?
Hi Portage takes up a lot of space and time when doing server backups. How much of Portage needs to be backup up? Any large parts of the tree that I can just dump? Thanks! CC appreciated :). -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Gentoo: State of the Union
If you want central control of what's happening in the repository, Subversion seems like the way to go. Better to fix the design of the repository, so that it can't be broken in the first place, than to try putting band-aids in place to cover the gaps. Wow, way out of scope. Sure, a Portage that's inherently unbreakable would be nice. And infinitely more difficult to carry out than what I was proposing. Also, the two (QA inline in commit process vs. Perfect Portage) does not preclude each other. While one may be better long term you can still do the other to improve quality short term. (Not that you would need to - if you had a QA step in the commit process to make sure that ebuild dependencies were never broken, why would you want to create a whole new Portage? I was trying to say that a QA tool in form of a SVN pre-commit hook seems like a perfect fit. The entire infrastructure to run an external application to check a commit before carrying it out, approve the commit, send appropriate error messages back to the SCM client and display them to the user etc. is already in place (and has been for years) in the Subversion server and any of the client tools. The amount of work involved between inventing a couple of rules that committed ebuilds must obey to actually implementing an enforcement of said rules is _very_ overcomeable with SVN. I wasn't even proposing that Gentoo actually needs a QA tool inline in the process, just saying that it can easily be done [with SVN] :-). PS. I resent calling it a band-aid. It'd be a QA tool built on the very well-thought-out foundation for quality assurance of commits that SVN pre-commit hooks happens to be. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Gentoo: State of the Union
Having a live tree requires people to be perfect. People are not perfect and requiring it is ridiculous. I love having commits in my local tree within the hour, but having a stable and unstable branch makes a lot of sense. Does it? How does having a stable and unstable branch differ from having stable and unstable keywords? Agreed. That doesn't make sense. Subversion has what is known as pre-commit hooks. Using those it's very easy to: * prevent (most or some) committers from designating ebuilds as stable * allow committers to designate ebuilds as stable under a certain path only * strictly limit a commiters access to a part of the tree Slightly harder, but could be done too: * deny commits if it breaks ebuild dependencies If you want central control of what's happening in the repository, Subversion seems like the way to go. SVN requires at least 2x the tree size for storage on the local machine, This is a feature, not a bug. It allows you to keep operations local, fx. do a diff without being online with the repository. checkouts take something akin to an order of magnitude longer than CVS. In the past Subversion performance was sub-par. I haven't systematically tested performance, but I would expect it to be much better now. Performance is gradually improved, see fx. r18867, r18944 and r19420: http://svn.collab.net/viewvc/svn?view=revrevision=18867 http://svn.collab.net/viewvc/svn?view=revrevision=18944 http://svn.collab.net/viewvc/svn?view=revrevision=19420 GIT might perform better, since Linus specifically emphasized non-O(n^2) performance in the design. But being a decentralized tool, I'm not sure how well it fits the needs here. The former is annoying, but liveable, but the latter is a deal-breaker. I don't think so. You really rarely do a complete checkout. - No changeset/merge tracking Solutions exist, including svnmerge and svk. Official solution actively worked on at the moment, check out the svn dev list. A benefit of Subversion that I personally like is that FSFS repositories are extremely easy to rsync. -- gentoo-dev@gentoo.org mailing list