Re: [gentoo-dev] RFC: reduce conflicts, separate keywording from ebuilds
Stefan Schweizer wrote: comments? just find a scriptable system to manage server side mass keywording... as in $EDITOR tokeywordfile (same syntax as package.keywords) repoman tokeywords tokeywordfile (repoman first checks it is applicable locally and then push it over the server while it will produce the same modify) people just rsyncing a portion of the tree will be fine, the bandwidth to upload the thing would be minimal, if we are willing to feel the pain we could use the same trick for the mirrors... I'm against changing the ebuild structure. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] RFC: reduce conflicts, separate keywording from ebuilds
To my fellow arguing Gentoo developers, due to the recent conflict concerning keywording I want to propose to separate keywording completely from ebuilds. The keywords would reside in a special file in profiles/, maybe even in more than one file to allow more granular permissions. For example only mips developers can access the mips keywording file then. The arch team can then decide themselves which ebuild they want to mark ~arch and they can take care of possible new dependencies themselves. Also currently kde keywording/stabling needs ~300 commits. The problem being that all changes files also get transferred in a rsync. A separate keywording file would be the only one changed thus greatly reducing the sync time. comments? Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: reduce conflicts, separate keywording from ebuilds
Monday, 19. February 2007, Stefan Schweizer Ви написали: To my fellow arguing Gentoo developers, due to the recent conflict concerning keywording I want to propose to separate keywording completely from ebuilds. The keywords would reside in a special file in profiles/, maybe even in more than one file to allow more granular permissions. For example only mips developers can access the mips keywording file then. Can you please clarify what exactly you are proposing. Is this a) move all the keywording into profiles (that is remove all KEYWORDS fields from all the ebuild) and disallow package maintainers and other devs (other than arch teams) to touch keywords or b) leave ebuilds with simple ~arch/arch/-arch (literally) keywords and move granular per-arch settings to profiles or something else? Even then I am not sure how either of these is going to work, especially this: The arch team can then decide themselves which ebuild they want to mark ~arch and they can take care of possible new dependencies themselves. normally new versions/packages go directly into ~arch unless they are transiently masked by developer (waiting for release, etc) or are permanently masked live-cvs/svn ones. I am not sure how a) is going to work at all in this respect. Are we going to get tons of ebuilds just sitting there never made visible to any arch now (since even x86 would have a large backlog)? b) seems more sane, but then the particulars of the interaction (of devs and arch teams) are not clear. George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: reduce conflicts, separate keywording from ebuilds
It was discussed at the last council meeting... Proposed by jokey. On Mon, Feb 19, 2007 at 10:54:55AM +0100, Stefan Schweizer wrote: To my fellow arguing Gentoo developers, due to the recent conflict concerning keywording I want to propose to separate keywording completely from ebuilds. The keywords would reside in a special file in profiles/, maybe even in more than one file to allow more granular permissions. For example only mips developers can access the mips keywording file then. The arch team can then decide themselves which ebuild they want to mark ~arch and they can take care of possible new dependencies themselves. Also currently kde keywording/stabling needs ~300 commits. The problem being that all changes files also get transferred in a rsync. A separate keywording file would be the only one changed thus greatly reducing the sync time. comments? Best regards, Stefan -- gentoo-dev@gentoo.org mailing list -- Alexander Færøy Bugday Lead Alpha/IA64/MIPS Architecture Teams User Relations, Quality Assurance pgp00Z49LOXnR.pgp Description: PGP signature
Re: [gentoo-dev] RFC: reduce conflicts, separate keywording from ebuilds
On Mon, Feb 19, 2007 at 10:54:55AM +0100, Stefan Schweizer wrote: To my fellow arguing Gentoo developers, due to the recent conflict concerning keywording I want to propose to separate keywording completely from ebuilds. The keywords would reside in a special file in profiles/, maybe even in more than one file to allow more granular permissions. For example only mips developers can access the mips keywording file then. The arch team can then decide themselves which ebuild they want to mark ~arch and they can take care of possible new dependencies themselves. Also currently kde keywording/stabling needs ~300 commits. The problem being that all changes files also get transferred in a rsync. A separate keywording file would be the only one changed thus greatly reducing the sync time. That's lame for several different reasons that I'm going to outline below and frankly anybody blowing steam about ~arch keywording the latest version (which ended up as being the goal yesterday) is being extremely silly. Anyway, here's several reasons why it's lame - I'm sure there's even more good reasons but these should suffer: A. ~arch keywords are supposed to be carried over to new versions unless we're talking about big rewrites or similar (so old versions doesn't have to linger around in portage tree at all). B. If we're complaining about MIPS team not being able to ~mips kde-meta on time we need to remove all the arch teams that falls behind from time. I think that leaves us with maybe x86, amd64, sparc as *the only* arch teams allowed to keyword kde-meta which is completely insane and an insult to our users. C. If (as Diego told me) portage is being too slow regenerating cache because of an extra 300 kde-meta ebuilds in the tree we have to sane options: - C1. Remove kde-meta completely as it's breaking our package manager. - C2. Fix portage immediately or switch to a package manager that works. Now, all of the above is insane as I think everybody can agree so please stop making a big fuss about this. An extra 300 kde-meta ebuilds shouldn't: D. Be in the tree at all unless KDE team thinks it's fun to drop all the ~arch keywords. E. Be a problem for the package manager (or we got bigger problems on our hand which would basically force us to stop adding new packages to the tree until resolved). Besides that splitting keywords out from ebuilds doesn't solve *anything* at all related to this as the ebuilds *still* have to stay around as long as they have keywords. Just like current policy says. Moving metadata to another place doesn't change that at all. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: reduce conflicts, separate keywording from ebuilds
On Monday 19 February 2007, Bryan Østergaard wrote: That's lame for several different reasons that I'm going to outline below and frankly anybody blowing steam about ~arch keywording the latest version (which ended up as being the goal yesterday) is being extremely silly. i dont add my voice to the discussion because Bryan seems to have covered plenty of what came to my mind -mike pgp44EgELzN4O.pgp Description: PGP signature
Re: [gentoo-dev] RFC: reduce conflicts, separate keywording from ebuilds
Dňa Mon, 19 Feb 2007 12:34:19 +0100 Bryan Østergaard [EMAIL PROTECTED] napísal: Anyway, here's several reasons why it's lame - I'm sure there's even more good reasons but these should suffer: Another reason would be that it would cripple (even more) the benefit of having all the relevant info in one place - the ebuild. Currently, everything is in the ebuild, except package.masks, which are in profiles. What OP is proposing would increase number of places to look for info from two to two plus number of supported archs. Not good. Please don't improve the current way of defining keywords just because some people got scary CVS conflict messages. Those happen all the time in larger repositories. Kind regards, -- Andrej Kacian ticho at gentoo org Gentoo Linux developer - net-mail, antivirus, sound, x86 signature.asc Description: PGP signature
