[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: package.mask
Peter Weller wrote: On Sun, 2008-06-22 at 15:49 +0200, Alin Nstac wrote: Peter Volkov wrote: ? ???, 21/06/2008 ? 10:56 +0200, Albert Zeyer ?: Perhaps install a script which automatically takes the CVS comment when some of these files is changed and adds this comment automatically to the ChangeLog? Some days ago Diego (flameeyes) suggested to write script which will abort commit in case ChangeLog is not filled. Taking into account a number (about 1 commit per day(!)) of developers who forgive to use echangelog I think this is the only way to go if we want that ChangeLog's to be useful... How about fixing the right problem instead forcing devs to complete yet another step? The right way of fixing that is by creating changelogs automatically, based on cvs commit comments. Possibly by making it a part of the whole repoman commit process? I'm pretty sure I've mentioned this in a council meeting: http://www.gentoo.org/proj/en/council/meeting-logs/20080508-summary.txt (Check the 'New Topics' - 'When are ChangeLog entries required?' summary) Well, sunrise-commit already has this option :-) And repoman still doesn't work in profiles/, right? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: package.mask
2008/6/22 Peter Weller [EMAIL PROTECTED]: On Sun, 2008-06-22 at 15:49 +0200, Alin Nstac wrote: Peter Volkov wrote: В Сбт, 21/06/2008 в 10:56 +0200, Albert Zeyer пишет: Perhaps install a script which automatically takes the CVS comment when some of these files is changed and adds this comment automatically to the ChangeLog? Some days ago Diego (flameeyes) suggested to write script which will abort commit in case ChangeLog is not filled. Taking into account a number (about 1 commit per day(!)) of developers who forgive to use echangelog I think this is the only way to go if we want that ChangeLog's to be useful... How about fixing the right problem instead forcing devs to complete yet another step? The right way of fixing that is by creating changelogs automatically, based on cvs commit comments. Possibly by making it a part of the whole repoman commit process? I'm pretty sure I've mentioned this in a council meeting: http://www.gentoo.org/proj/en/council/meeting-logs/20080508-summary.txt (Check the 'New Topics' - 'When are ChangeLog entries required?' summary) The portage team is always open for repoman improvements ;) -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] dev-python/setuptools as RDEPEND
Just a quick note here in case you work on Python packages. Recently repoman started warning that setuptools may be suspicious as an RDEPEND. A lot of Python packages use another namespace that setuptools provides, 'pkg_resources', for plugin systems so it may not appear obvious that setuptools is an RDEPEND. I've updated the Python Developer's Guide[1] with info on how you can easily determine if it's an RDEPEND or not. [1] http://www.gentoo.org/proj/en/Python/developersguide.xml -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Merging or overwriting KEYWORDS from eclass
Hi, I've stumbled upon an inconsitency between package managers the other day [1], which was due to both an ebuild and an eclass defining inconsisting KEYWORDS. bla-1.ebuild: inherit myeclass KEYWORDS=~arch myeclass.eclass: KEYWORDS=arch Portage will resolve this by overwriting the variable, so the last (~arch) wins. Paludis, on the other hand, merges the variables, so it is KEYWORDS=~arch arch. The PMS draft [2] defines that IUSE, DEPEND, RDEPEND and PDEPEND variables be merged when defined in both eclass and ebuild (Section 7.2), but only says May be defined in an eclass about KEYWORDS (Section 8.2). Anyone up to toss a coin whose bug it is, and maybe we can have a more specific wording in the PMS? Robert [1] http://trac.pioto.org/paludis/ticket/586#comment:10 [2] http://dev.gentoo.org/~coldwind/pms-without-kdebuild.pdf signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Merging or overwriting KEYWORDS from eclass
On Tue, Jun 24, 2008 at 01:53:55AM +0200, Robert Buchholz wrote: Hi, I've stumbled upon an inconsitency between package managers the other day [1], which was due to both an ebuild and an eclass defining inconsisting KEYWORDS. bla-1.ebuild: inherit myeclass KEYWORDS=~arch myeclass.eclass: KEYWORDS=arch Portage will resolve this by overwriting the variable, so the last (~arch) wins. Paludis, on the other hand, merges the variables, so it is KEYWORDS=~arch arch. The PMS draft [2] defines that IUSE, DEPEND, RDEPEND and PDEPEND variables be merged when defined in both eclass and ebuild (Section 7.2), but only says May be defined in an eclass about KEYWORDS (Section 8.2). Anyone up to toss a coin whose bug it is, and maybe we can have a more specific wording in the PMS? Paludis bug; if you want KEYWORDS incremental, it'll need to be in =eapi2, too nasty of a change to shoehorn into existing (in use) eapis. Cheers, ~harring pgpGcmR0UL61B.pgp Description: PGP signature
