Re: [gentoo-dev] dev-python/setuptools as RDEPEND
On 23-06-2008 15:21:31 -0700, Rob Cakebread wrote: > 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. Why not remove the check from repoman, if it is a false positive in many cases? > [1] http://www.gentoo.org/proj/en/Python/developersguide.xml -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Merging or overwriting KEYWORDS from eclass
Brian Harring wrote: > 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 de?ned 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. hmm, the program you use for posting should really have a delay function in case you respond too fast (1:25 according to my news reader, gmane and the assumption clocks are in sync). well, if the PMS doesn't say anything about it, it's a lack of specification and not a bug of a package manager. Can you please give more info why this is "too nasty"? Cheers, Tiziano -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Suggested default LDFLAGS+="-Wl,-O1,--hash-style=gnu,--sort-common"
I would like to suggest that default LDFLAGS in Gentoo contain the following flags: "-Wl,-O1,--hash-style=gnu,--sort-common". -O1 enables some basic optimizations. --hash-style=gnu causes that ld creates only new GNU-style hash tables. --sort-common causes that ld sorts the common symbols by size when it places them in the appropriate output sections. These options don't cause any problems, so they should be less controversial than --as-needed. (These options don't conflict with --as-needed, so --as-needed can be still added to default LDFLAGS, but this thread isn't about --as-needed.) -- Arfrever Frehtes Taifersar Arahesis -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Suggested default LDFLAGS+="-Wl,-O1,--hash-style=gnu,--sort-common"
On 24-06-2008 14:15:10 +0200, Arfrever Frehtes Taifersar Arahesis wrote: > I would like to suggest that default LDFLAGS in Gentoo contain the following > flags: "-Wl,-O1,--hash-style=gnu,--sort-common". > > -O1 enables some basic optimizations. > --hash-style=gnu causes that ld creates only new GNU-style hash tables. > --sort-common causes that ld sorts the common symbols by size when it places > them in the appropriate output sections. > > These options don't cause any problems, so they should be less controversial > than --as-needed. > (These options don't conflict with --as-needed, so --as-needed can be still > added to default LDFLAGS, but this thread isn't about --as-needed.) as long as it doesn't go in /base, but in the linux/freebsd profiles instead, it's fine with me. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Suggested default LDFLAGS+="-Wl,-O1,--hash-style=gnu,--sort-common"
Fabian Groffen <[EMAIL PROTECTED]> writes: > as long as it doesn't go in /base, but in the linux/freebsd profiles > instead, it's fine with me. --has-style=gnu should not be used on non-GLIBC systems (I'm unsure about uclibc, but I'd be surprised if they do implement the GNU style hash). -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpmivCa8PtPJ.pgp Description: PGP signature
Re: [gentoo-dev] Re: Merging or overwriting KEYWORDS from eclass
On Tue, Jun 24, 2008 at 12:05:39PM +0200, Tiziano M??ller wrote: > Brian Harring wrote: > > > 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 de?ned 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. > well, if the PMS doesn't say anything about it, it's a lack of specification > and not a bug of a package manager. Falls to the same people regardless; in this case it is a bug of the manager since longstanding behaviour of keywords from eclasses has *always* been non-incremental. Regardless, omission of keywords from the list of incremental eclasses doesn't equate to "do what you want"- it means "it's not incremental". > Can you please give more info why this is "too nasty"? The original post gave an example of why this can't be shoehorned in- bla-1, instead of being marked unstable, becomes stable. I might add that it becomes stable effectively *always* also due to stable keywords existing in eclass. The use case for this isn't particularly grand either- the only real use case for such behaviour is shifting unstable keywords into the eclass, and storing the stable keywords in the ebuild. Problem with that however is that if a consumer of the eclass ever needs to be marked unusable (temporarily or otherwise) for a specific arch, the paludis keyword stacking means that the eclass would have to have that arch pruned from the eclass (sticking -$ARCH into the ebuild would most likely not suffice due to existing portage keyword visibility filters). Basically, if we were talking about tweaking IUSE, then I'd be singing a different tune- KEYWORDS behaviour, specifically keywords visibility filtering of available packages means that this isn't easily changable w/out resulting in past managers that worked properly, no longer working properly. For IUSE, you could likely get away with shoehorning this in- older managers generally didn't care much about IUSE (although built_with_use is a notable exception). Cheers. ~brian pgp9ke0PHjt3J.pgp Description: PGP signature
[gentoo-dev] Last rites: =dev-lang/python-2.3* (Second try)
Now that the packages depending on 2.3 are masked, masking this one again for removal in 30 days. -- Regards, Ali Polatel pgpN7f7hYDgvJ.pgp Description: PGP signature
Re: [gentoo-dev] Merging or overwriting KEYWORDS from eclass
В Втр, 24/06/2008 в 01:53 +0200, Robert Buchholz пишет: > 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. But do we allow KEYWORDS in eclasses? Why? Each package should be tested independently on each arch and there is no sane way to test all ebuilds that inherit eclass... Or do we have exceptions? If so, then ebuilds for dictionaries and stardict.eclass could be perfect exception, but QA team prohibited usage of KEYWORDS in stadict eclass. See bug 163833 . -- Peter. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Suggested default LDFLAGS+="-Wl,-O1,--hash-style=gnu,--sort-common"
On Tue, 24 Jun 2008 14:17:48 +0200 Fabian Groffen <[EMAIL PROTECTED]> wrote: > On 24-06-2008 14:15:10 +0200, Arfrever Frehtes Taifersar Arahesis > wrote: > > I would like to suggest that default LDFLAGS in Gentoo contain the > > following flags: "-Wl,-O1,--hash-style=gnu,--sort-common". > > > > -O1 enables some basic optimizations. > > --hash-style=gnu causes that ld creates only new GNU-style hash > > tables. --sort-common causes that ld sorts the common symbols by > > size when it places them in the appropriate output sections. > > > > These options don't cause any problems, so they should be less > > controversial than --as-needed. > > (These options don't conflict with --as-needed, so --as-needed can > > be still added to default LDFLAGS, but this thread isn't about > > --as-needed.) > > as long as it doesn't go in /base, but in the linux/freebsd profiles > instead, it's fine with me. Ditto. mips doesn't have support for .gnu.hash. Currently --hash-style=both is set in the binutils patchset, not the profiles so it's kind of a global setting. Can the profiles override it? -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
