Re: [gentoo-dev] adns & ares USE flags
On 28 August 2012 05:11, Michał Górny wrote: > Hello, > > $ quse -D adns ares > global:adns: Adds support for the adns DNS client library > local:ares:dev-libs/ecore: Enables support for asynchronous DNS using the > net-dns/c-ares library > local:ares:net-analyzer/wireshark: Use GNU net-dns/c-ares library to resolve > DNS names > local:ares:net-irc/znc: Enables support for asynchronous DNS using the > c-ares library > local:ares:net-misc/aria2: Enables support for asynchronous DNS using the > c-ares library > local:ares:net-misc/curl: Enabled c-ares dns support > local:ares:net-p2p/gift: pull in Ares plugin > > Both of the flags (except for gift AFAICS) refer to asynchronous DNS > resolution. Could we join them into one flag? I think we should retain > 'adns', move appropriate 'ares' flags to it and modify the description > to make it less library-centric. Sounds like a good idea to me. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Any official position from Gentoo about systemd, mdev and udev-static ?
On 29 August 2012 01:36, Luca Barbato wrote: > On 08/28/2012 05:35 PM, Sylvain Alain wrote: >> Hi everyone, I don't want to start a flamewar on that subject, but I would >> like to know if there's any official position about the current situation. > > udev might or might not eventually get forked to avoid systemd > borg-approach. > > mdev works fine for a number of people and they are working on getting > better support for it even if some guys sometimes try to stomp over them > for silly reasons. > > openrc during the summer got new features developed both for prefix > users and for general public hopefully will get merged soon. > > The consensus is trying to support what makes sense of systemd and let > people use it if they really want but not force it upon people happy or > needing openrc. > > Beside that you have drama since there are strong opinions on how broken > systemd is or how cool it is. > >> I saw on the forum this thread : >> https://forums.gentoo.org/viewtopic-t-934678-highlight-.html and maybe it >> could be part of a solution to have OpenRC and udev together. >> >> So, is there any developments lately ? > > Lots =) > > lu > I think this is a fairly good overview of the current situation. The way I see it: Gentoo defaults to OpenRC and stand-alone udev. This is not going to change any time soon. Because some developers think systemd is a worthwhile alternative, they are making it possible for Gentoo users to switch to using this if they want to. Gentoo is about choice, after all. But there is also strong opposition towards systemd and the "our way or no way" attitude of its core developers, so it is unlikely Gentoo will adopt systemd. It would be too controversial and lead to a rift in the developer community. For now udev is still usable without systemd, even tho upstream is making it difficult to build udev separately (and avoid unnecessary build-time dependencies). Upstream is also unwilling to work with us to make this easier. Despite upstream promises that udev will remain usable stand-alone, there is a lot of skepticism towards that. So we may find ourselves faced with the need to use a fork or a replacement for udev. Right now the situation is in flux, so we are basically waiting to see how things will develop. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] supporting static-libs
On 28/08/2012 15:36, Mart Raudsepp wrote: > static-libs is for installing static libraries IN ADDITION to shared > libraries, not instead. > USE=static is for what you have in mind there. PE is not the same as ELF so on Windows you either build one or the other for a number of reasons. Now on a different note, this is not even what USE=static is for — but that's way behind what we were discussing before. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] supporting static-libs
On N, 1970-01-01 at 00:00 +, Gregory M. Turner wrote:
> On 8/28/2012 1:09 AM, Michał Górny wrote:
> > On Tue, 28 Aug 2012 02:15:40 +0200
> > hasufell wrote:
> >> static-libs
> > pointless
>
> I have to mask this flag for dev-libs/{gmp,mpc} in my cygwin overlay,
> where one can have static or dynamic, but not both, as per. upstream
> requirements (no idea why). So FTR, this is not always a matter of
> personal taste.
static-libs is for installing static libraries IN ADDITION to shared
libraries, not instead.
USE=static is for what you have in mind there.
Best,
Mart Raudsepp
Re: [gentoo-dev] supporting static-libs
On 8/28/2012 1:09 AM, Michał Górny wrote:
On Tue, 28 Aug 2012 02:15:40 +0200
hasufell wrote:
static-libs
pointless
I have to mask this flag for dev-libs/{gmp,mpc} in my cygwin overlay,
where one can have static or dynamic, but not both, as per. upstream
requirements (no idea why). So FTR, this is not always a matter of
personal taste.
-gmt
Re: [gentoo-dev] Any official position from Gentoo about systemd, mdev and udev-static ?
On 08/28/2012 05:35 PM, Sylvain Alain wrote: > Hi everyone, I don't want to start a flamewar on that subject, but I would > like to know if there's any official position about the current situation. udev might or might not eventually get forked to avoid systemd borg-approach. mdev works fine for a number of people and they are working on getting better support for it even if some guys sometimes try to stomp over them for silly reasons. openrc during the summer got new features developed both for prefix users and for general public hopefully will get merged soon. The consensus is trying to support what makes sense of systemd and let people use it if they really want but not force it upon people happy or needing openrc. Beside that you have drama since there are strong opinions on how broken systemd is or how cool it is. > I saw on the forum this thread : > https://forums.gentoo.org/viewtopic-t-934678-highlight-.html and maybe it > could be part of a solution to have OpenRC and udev together. > > So, is there any developments lately ? Lots =) lu
Re: [gentoo-dev] Any official position from Gentoo about systemd, mdev and udev-static ?
On Tue, Aug 28, 2012 at 1:03 PM, Jeff Horelick wrote: > I think this issue is currently in far too murky of a state to get any > well-informed issue from the council. Perhaps when the issues get > hammered out a bit more, but not currently. I tend to agree. Taking a position for or against some piece of technology doesn't really make sense. Making a decision on some implementation detail that has a real impact on the distro makes sense. It is hard to anticipate what kinds of crises will continue to arise. So, best to deal with them one at a time. Of course, it would be best if the various package maintainers could talk to each other to anticipate issues BEFORE they arise. If upstream wants to rename or move half their binaries and the maintainers want to follow upstream, I don't have a big problem with that per se, but at least talk about it on the lists before unmasking things/etc. Best to keep the council decisions actionable. And it is probably best to let the directly impacted maintainers be the ones to appeal to the council if the concern is breakage/etc. If we were less of an enthusiast/choice distro then the obviously solution would be to just ship a working udev and wait and see how the whole mess works itself out elsewhere. It will be messy for a while for Gentoo, because we generally strive to be "interesting." :) Rich
Re: [gentoo-dev] Any official position from Gentoo about systemd, mdev and udev-static ?
On 28 August 2012 12:59, Matthew Thode wrote: > On 08/28/2012 10:35 AM, Sylvain Alain wrote: >> Hi everyone, I don't want to start a flamewar on that subject, but I would >> like to know if there's any official position about the current situation. >> >> I saw on the forum this thread : >> https://forums.gentoo.org/viewtopic-t-934678-highlight-.html and maybe it >> could be part of a solution to have OpenRC and udev together. >> >> So, is there any developments lately ? >> >> Thanks ! >> >> d2_racing >> > > Maybe something to get at least some general direction from council, > though probably too technical. > > -- > -- Matthew Thode (prometheanfire) > I think this issue is currently in far too murky of a state to get any well-informed issue from the council. Perhaps when the issues get hammered out a bit more, but not currently.
Re: [gentoo-dev] Any official position from Gentoo about systemd, mdev and udev-static ?
On 08/28/2012 10:35 AM, Sylvain Alain wrote: > Hi everyone, I don't want to start a flamewar on that subject, but I would > like to know if there's any official position about the current situation. > > I saw on the forum this thread : > https://forums.gentoo.org/viewtopic-t-934678-highlight-.html and maybe it > could be part of a solution to have OpenRC and udev together. > > So, is there any developments lately ? > > Thanks ! > > d2_racing > Maybe something to get at least some general direction from council, though probably too technical. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Any official position from Gentoo about systemd, mdev and udev-static ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/08/12 11:47 AM, Rich Freeman wrote: > On Tue, Aug 28, 2012 at 11:35 AM, Sylvain Alain > wrote: >> Hi everyone, I don't want to start a flamewar on that subject, >> but I would like to know if there's any official position about >> the current situation. > > There is not. But thanks for starting the flamewar just the same. > :) > SYSTEMD OR DEATH!!! ..err.. UDEV FREEDOM FOREVER!!! ... (that about covers it, yeah? so we can all move on now?) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlA86t4ACgkQ2ugaI38ACPBuHQD9FsdNxrjY6UTTpHkp81IkSrcl z0HaPLKC9Ju1orRaQQgA/10Yn29tSt54yc8ieftOeAK2v9+rX4rbl17cLKy+TYOL =86v4 -END PGP SIGNATURE-
Re: [gentoo-dev] Any official position from Gentoo about systemd, mdev and udev-static ?
On Tue, Aug 28, 2012 at 11:35 AM, Sylvain Alain wrote: > Hi everyone, I don't want to start a flamewar on that subject, but I would > like to know if there's any official position about the current situation. There is not. But thanks for starting the flamewar just the same. :) > > I saw on the forum this thread : > https://forums.gentoo.org/viewtopic-t-934678-highlight-.html and maybe it > could be part of a solution to have OpenRC and udev together. > I'm sure nobody would object to somebody putting it in the tree - somebody just has to do it, or start their own overlay. The systemd folks would seem to prefer to just bundle udev with systemd anyway, making it a virtual. Gentoo is about choice. Perhaps some day installing a sysvinit implementation will be like installing a cron daemon. Or, perhaps it will become a nightmare as the various forks all strive to make life as difficult as possible for anybody using the "wrong" one. > So, is there any developments lately ? Uh, probably only about 500 emails in the last two months. I'd suggest reading the archives, but they'll probably look like the archives on every other distro -dev mailing list. Rich
[gentoo-dev] Any official position from Gentoo about systemd, mdev and udev-static ?
Hi everyone, I don't want to start a flamewar on that subject, but I would like to know if there's any official position about the current situation. I saw on the forum this thread : https://forums.gentoo.org/viewtopic-t-934678-highlight-.html and maybe it could be part of a solution to have OpenRC and udev together. So, is there any developments lately ? Thanks ! d2_racing -- Salut alp Sylvain
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
On Tue, 28 Aug 2012 10:45:59 -0400
Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 28/08/12 10:43 AM, Michał Górny wrote:
> > On Tue, 28 Aug 2012 10:10:01 +0200 Tiziano Müller
> > wrote:
> >
> >> Am Dienstag, den 28.08.2012, 10:06 +0200 schrieb Michał Górny:
> >>> On Tue, 28 Aug 2012 06:26:02 +0200 Arfrever Frehtes Taifersar
> >>> Arahesis wrote:
> >>>
> 2012-08-28 00:19:28 Michał Górny napisał(a):
> > --- /dev/null +++ b/gx86/eclass/boost-utils.eclass @@ -0,0
> > +1,43 @@ +# Copyright 1999-2012 Gentoo Foundation +#
> > Distributed under the terms of the GNU General Public
> > License v2 +# $Header: $ + +if [[ ! ${_BOOST_ECLASS} ]];
> > then + +# @ECLASS: boost-utils.eclass +# @MAINTAINER: +#
> > mgo...@gentoo.org
>
> It is better to copy list of maintainers from
> gentoo-x86/dev-libs/boost/metadata.xml.
>
> > +# @BLURB: helper functions for packages using Boost C++
> > library +# @DESCRIPTION: +# Helper functions to be used
> > when building packages using the Boost C++ +# library
> > collection. + +case ${EAPI:-0} in + 0|1|2|3|4) ;;
> > + *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
> > established." +esac
>
> Please accept all EAPIs.
> >>>
> >>> These are EAPIs which are allowed throughout the tree, sorry.
> >>> Feel free to ping Council about adding non-standard EAPIs to
> >>> eclasses.
> >>>
> > +inherit versionator + +# @FUNCTION:
> > boost-utils_get_best_slot +# @DESCRIPTION: +# Get newest
> > SLOT (major version) of Boost. +boost-utils_get_best_slot()
> > { + local pkg=dev-libs/boost + local
> > atom=$(best_version ${pkg}) +
> > get_version_component_range 1-2 ${atom#${pkg}} +} + +#
> > @FUNCTION: boost-utils_get_includedir +# @DESCRIPTION: +# Get
> > correct includedir for best Boost version. Outputs the sole
> > path +# (without -I). +boost-utils_get_includedir() { +
> > local slot=$(boost-utils_get_best_slot) + has
> > "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX= + + echo
> > -n "${EPREFIX}/usr/include/boost-${slot/./_}" +}
>
> There needs to be a way to specify maximal accepted slot of
> Boost. Examples of some possibilities: *
> BOOST_MAX_SLOT="1.49" global variable * '--max 1.49'
> arguments for boost-utils_get_* functions
> >>>
> >>> I'd rather wait with that till Tiziano expresses his opinion.
> >>> I think the policy ought to be 'always prefer newest version'
> >>> but I guess that's hard with boost.
> >>>
> >>
> >> one of the points of having a slotted boost (besides solving the
> >> rebuild when API/ABI breakages occur) is that a package may also
> >> use an older boost slot (currently it only would make sense if
> >> we'd backport the glibc-2.16 patches but that's a different
> >> story). So I'd prefer if we'd have a BOOST_MAX_SLOT variable.
> >
> > Do we want to support using random old versions of boost then or
> > just the newest supported SLOT? If the latter, we could get away
> > without using best_version, and just request devs to depend on
> > specific boost slot then.
> >
>
> IIRC from comments on IRC, the idea with boost is that "newest
> available" is what is recommended to be used, but obviously "newest
> supported by ebuild" would take precedence, if a package can't be
> built against a newer boost.
>
> Otherwise why would we bother to slot in the first place?
I meant 'require only newest slot supported by package' vs 'any older
slot would work'.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 28/08/12 10:43 AM, Michał Górny wrote:
> On Tue, 28 Aug 2012 10:10:01 +0200 Tiziano Müller
> wrote:
>
>> Am Dienstag, den 28.08.2012, 10:06 +0200 schrieb Michał Górny:
>>> On Tue, 28 Aug 2012 06:26:02 +0200 Arfrever Frehtes Taifersar
>>> Arahesis wrote:
>>>
2012-08-28 00:19:28 Michał Górny napisał(a):
> --- /dev/null +++ b/gx86/eclass/boost-utils.eclass @@ -0,0
> +1,43 @@ +# Copyright 1999-2012 Gentoo Foundation +#
> Distributed under the terms of the GNU General Public
> License v2 +# $Header: $ + +if [[ ! ${_BOOST_ECLASS} ]];
> then + +# @ECLASS: boost-utils.eclass +# @MAINTAINER: +#
> mgo...@gentoo.org
It is better to copy list of maintainers from
gentoo-x86/dev-libs/boost/metadata.xml.
> +# @BLURB: helper functions for packages using Boost C++
> library +# @DESCRIPTION: +# Helper functions to be used
> when building packages using the Boost C++ +# library
> collection. + +case ${EAPI:-0} in + 0|1|2|3|4) ;; + *) die
> "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
> +esac
Please accept all EAPIs.
>>>
>>> These are EAPIs which are allowed throughout the tree, sorry.
>>> Feel free to ping Council about adding non-standard EAPIs to
>>> eclasses.
>>>
> +inherit versionator + +# @FUNCTION:
> boost-utils_get_best_slot +# @DESCRIPTION: +# Get newest
> SLOT (major version) of Boost. +boost-utils_get_best_slot()
> { + local pkg=dev-libs/boost + local atom=$(best_version
> ${pkg}) + get_version_component_range 1-2 ${atom#${pkg}}
> +} + +# @FUNCTION: boost-utils_get_includedir +#
> @DESCRIPTION: +# Get correct includedir for best Boost
> version. Outputs the sole path +# (without -I).
> +boost-utils_get_includedir() { + local
> slot=$(boost-utils_get_best_slot) + has "${EAPI:-0}" 0 1 2
> && ! use prefix && EPREFIX= + + echo -n
> "${EPREFIX}/usr/include/boost-${slot/./_}" +}
There needs to be a way to specify maximal accepted slot of
Boost. Examples of some possibilities: *
BOOST_MAX_SLOT="1.49" global variable * '--max 1.49'
arguments for boost-utils_get_* functions
>>>
>>> I'd rather wait with that till Tiziano expresses his opinion.
>>> I think the policy ought to be 'always prefer newest version'
>>> but I guess that's hard with boost.
>>>
>>
>> one of the points of having a slotted boost (besides solving the
>> rebuild when API/ABI breakages occur) is that a package may also
>> use an older boost slot (currently it only would make sense if
>> we'd backport the glibc-2.16 patches but that's a different
>> story). So I'd prefer if we'd have a BOOST_MAX_SLOT variable.
>
> Do we want to support using random old versions of boost then or
> just the newest supported SLOT? If the latter, we could get away
> without using best_version, and just request devs to depend on
> specific boost slot then.
>
IIRC from comments on IRC, the idea with boost is that "newest
available" is what is recommended to be used, but obviously "newest
supported by ebuild" would take precedence, if a package can't be
built against a newer boost.
Otherwise why would we bother to slot in the first place?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlA82acACgkQ2ugaI38ACPAc0gD+Ohokg0d6MAikZfLsyenyBnb6
PMIRVUI3VtHXcOz1cG4BALV9qTK1qSSUnNenRjjJxktdZ0f1Jatb69R+x9JXVM2m
=cIfW
-END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 28/08/12 10:35 AM, Mike Gilbert wrote:
> On Tue, Aug 28, 2012 at 4:06 AM, Michał Górny
> wrote:
>> On Tue, 28 Aug 2012 06:26:02 +0200 Arfrever Frehtes Taifersar
>> Arahesis wrote:
>>
>>> 2012-08-28 00:19:28 Michał Górny napisał(a):
+case ${EAPI:-0} in + 0|1|2|3|4) ;; + *) die
"${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
+esac
>>>
>>> Please accept all EAPIs.
>>
>> These are EAPIs which are allowed throughout the tree, sorry.
>> Feel free to ping Council about adding non-standard EAPIs to
>> eclasses.
>>
>
> Is the eclass likely to be incompatible with future EAPIs? If not,
> I think it is reasonable to remove this check.
>
It's quite standard to have the above check in place; and since there
is no guarantee that new EAPIs *won't* break something, I think it
would be a good idea to leave this as-is.
Yes this will add a touch more work when it comes to bumping eclasses
to accept EAPI=5 or newer, but forcing a dev to check the eclass's
compatibility when a new EAPI rolls out is a good thing imo.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlA82ToACgkQ2ugaI38ACPA4LQEAhoW6FtSwDqTdsV84XOjsibOp
TdM1B3sE8Gpp8WnfFhgA/3MvQy9oq+y/0U1cqMByiSAH4wN/12f0yuvGiWYD5pXf
=GQ4U
-END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
On Tue, 28 Aug 2012 10:10:01 +0200
Tiziano Müller wrote:
> Am Dienstag, den 28.08.2012, 10:06 +0200 schrieb Michał Górny:
> > On Tue, 28 Aug 2012 06:26:02 +0200
> > Arfrever Frehtes Taifersar Arahesis wrote:
> >
> > > 2012-08-28 00:19:28 Michał Górny napisał(a):
> > > > --- /dev/null
> > > > +++ b/gx86/eclass/boost-utils.eclass
> > > > @@ -0,0 +1,43 @@
> > > > +# Copyright 1999-2012 Gentoo Foundation
> > > > +# Distributed under the terms of the GNU General Public
> > > > License v2 +# $Header: $
> > > > +
> > > > +if [[ ! ${_BOOST_ECLASS} ]]; then
> > > > +
> > > > +# @ECLASS: boost-utils.eclass
> > > > +# @MAINTAINER:
> > > > +# mgo...@gentoo.org
> > >
> > > It is better to copy list of maintainers from
> > > gentoo-x86/dev-libs/boost/metadata.xml.
> > >
> > > > +# @BLURB: helper functions for packages using Boost C++ library
> > > > +# @DESCRIPTION:
> > > > +# Helper functions to be used when building packages using the
> > > > Boost C++ +# library collection.
> > > > +
> > > > +case ${EAPI:-0} in
> > > > + 0|1|2|3|4) ;;
> > > > + *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
> > > > established." +esac
> > >
> > > Please accept all EAPIs.
> >
> > These are EAPIs which are allowed throughout the tree, sorry. Feel
> > free to ping Council about adding non-standard EAPIs to eclasses.
> >
> > > > +inherit versionator
> > > > +
> > > > +# @FUNCTION: boost-utils_get_best_slot
> > > > +# @DESCRIPTION:
> > > > +# Get newest SLOT (major version) of Boost.
> > > > +boost-utils_get_best_slot() {
> > > > + local pkg=dev-libs/boost
> > > > + local atom=$(best_version ${pkg})
> > > > + get_version_component_range 1-2 ${atom#${pkg}}
> > > > +}
> > > > +
> > > > +# @FUNCTION: boost-utils_get_includedir
> > > > +# @DESCRIPTION:
> > > > +# Get correct includedir for best Boost version. Outputs the
> > > > sole path +# (without -I).
> > > > +boost-utils_get_includedir() {
> > > > + local slot=$(boost-utils_get_best_slot)
> > > > + has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
> > > > +
> > > > + echo -n "${EPREFIX}/usr/include/boost-${slot/./_}"
> > > > +}
> > >
> > > There needs to be a way to specify maximal accepted slot of Boost.
> > > Examples of some possibilities:
> > > * BOOST_MAX_SLOT="1.49" global variable
> > > * '--max 1.49' arguments for boost-utils_get_* functions
> >
> > I'd rather wait with that till Tiziano expresses his opinion. I
> > think the policy ought to be 'always prefer newest version' but I
> > guess that's hard with boost.
> >
>
> one of the points of having a slotted boost (besides solving the
> rebuild when API/ABI breakages occur) is that a package may also use
> an older boost slot (currently it only would make sense if we'd
> backport the glibc-2.16 patches but that's a different story). So I'd
> prefer if we'd have a BOOST_MAX_SLOT variable.
Do we want to support using random old versions of boost then or just
the newest supported SLOT? If the latter, we could get away without
using best_version, and just request devs to depend on specific boost
slot then.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-crypt/gpa: gpa-0.9.3.ebuild ChangeLog gpa-0.9.1_pre20100416-r1.ebuild
On Tue, Aug 28, 2012 at 9:56 AM, Alec Warner wrote: > > I'm not sure if you have noticed, but many developers in Gentoo > dislike process ;) > And I'd count myself chief among them. But then again, compared to what it takes at work to do anything productive, the "process" at Gentoo just seems like common sense. :) Rich
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
On Tue, Aug 28, 2012 at 4:06 AM, Michał Górny wrote:
> On Tue, 28 Aug 2012 06:26:02 +0200
> Arfrever Frehtes Taifersar Arahesis wrote:
>
>> 2012-08-28 00:19:28 Michał Górny napisał(a):
>> > --- /dev/null
>> > +++ b/gx86/eclass/boost-utils.eclass
>> > @@ -0,0 +1,43 @@
>> > +# Copyright 1999-2012 Gentoo Foundation
>> > +# Distributed under the terms of the GNU General Public License v2
>> > +# $Header: $
>> > +
>> > +if [[ ! ${_BOOST_ECLASS} ]]; then
>> > +
>> > +# @ECLASS: boost-utils.eclass
>> > +# @MAINTAINER:
>> > +# mgo...@gentoo.org
>>
>> It is better to copy list of maintainers from
>> gentoo-x86/dev-libs/boost/metadata.xml.
>>
>> > +# @BLURB: helper functions for packages using Boost C++ library
>> > +# @DESCRIPTION:
>> > +# Helper functions to be used when building packages using the
>> > Boost C++ +# library collection.
>> > +
>> > +case ${EAPI:-0} in
>> > + 0|1|2|3|4) ;;
>> > + *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
>> > established." +esac
>>
>> Please accept all EAPIs.
>
> These are EAPIs which are allowed throughout the tree, sorry. Feel free
> to ping Council about adding non-standard EAPIs to eclasses.
>
Is the eclass likely to be incompatible with future EAPIs? If not, I
think it is reasonable to remove this check.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-crypt/gpa: gpa-0.9.3.ebuild ChangeLog gpa-0.9.1_pre20100416-r1.ebuild
On Tue, Aug 28, 2012 at 4:25 AM, Rich Freeman wrote: > On Mon, Aug 27, 2012 at 10:05 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> That's all I'm saying. It's being made a whole lot less pleasant that it >> might be... for what reason? Just to satisfy someone's ego that they're >> right and can /force/ compliance? Yuck! > > Honestly, while I might agree with that sentiment on some of these > threads, my only complaint with Ciaran's original response was that he > could have been a bit more direct with his concern. Rather than > stating that EXTRA_* does not exist as far as ebuilds go, he could > have just stated that PMS does not allow these variables to be used by > an ebuild. > > However, the reply to that email makes it clear that even though it > was unstated Ciaran's meaning was understood. > > Sure, he didn't get into the why, but I'm not sure I'd expect that. > I'd probably state it, but I'm probably the second-most-verbose person > on this list. :) > > If somebody filed a bug against my package and pointed out that > something was illegal per PMS, probably the first thing I'd do is read > it to fully understand the situation, and then if I had a concern I'd > probably ask via irc/private email/etc. That is as much to avoid > making a fool out of myself in public, but also because when somebody > who is obviously knowledgeable points out something they consider a > flaw, it isn't a bad idea to give their concern full consideration. > > Sure, if PMS is wrong it ought to be fixed, but the whole point of > having specifications is that you don't toss them the moment you don't > like what they say. Then again, I work on regulated software in my > real job, and even if the spec is wrong changing it still involves a > process - you don't just ignore it (any behavior in violation of the > spec is an automatic bug - even if the bug is to fix the spec - and > unless pretty trivial is justification to prevent release (often this > is done anyway since it is usually less work to just fix the problem > than justify to the world not doing it)). I'm not sure if you have noticed, but many developers in Gentoo dislike process ;) > > In any case, it is best to not take these sorts of things personally > all around. Most of us are here because our perverse tastes consider > this stuff fun! :) Might as well keep it that way... > > Rich >
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
Am Dienstag, den 28.08.2012, 09:43 +0200 schrieb hasufell: > On 08/28/2012 06:26 AM, Arfrever Frehtes Taifersar Arahesis wrote: > > > > There needs to be a way to specify maximal accepted slot of Boost. > > Examples of some possibilities: * BOOST_MAX_SLOT="1.49" global > > variable * '--max 1.49' arguments for boost-utils_get_* functions > > > > Exactly. I don't see any reason for this eclass except this feature. > The current expected behavior of boost and build systems is that > always the latest installed will be picked. > > In fact this breaks packages in 3 of 4 cases on new boost versions. > > And while we are it it, we can punt the useless eselect implementation. boost-1.50 already removes symlinks created by eselect-boost and doesn't depend on it anymore.
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
Am Dienstag, den 28.08.2012, 10:06 +0200 schrieb Michał Górny:
> On Tue, 28 Aug 2012 06:26:02 +0200
> Arfrever Frehtes Taifersar Arahesis wrote:
>
> > 2012-08-28 00:19:28 Michał Górny napisał(a):
> > > --- /dev/null
> > > +++ b/gx86/eclass/boost-utils.eclass
> > > @@ -0,0 +1,43 @@
> > > +# Copyright 1999-2012 Gentoo Foundation
> > > +# Distributed under the terms of the GNU General Public License v2
> > > +# $Header: $
> > > +
> > > +if [[ ! ${_BOOST_ECLASS} ]]; then
> > > +
> > > +# @ECLASS: boost-utils.eclass
> > > +# @MAINTAINER:
> > > +# mgo...@gentoo.org
> >
> > It is better to copy list of maintainers from
> > gentoo-x86/dev-libs/boost/metadata.xml.
> >
> > > +# @BLURB: helper functions for packages using Boost C++ library
> > > +# @DESCRIPTION:
> > > +# Helper functions to be used when building packages using the
> > > Boost C++ +# library collection.
> > > +
> > > +case ${EAPI:-0} in
> > > + 0|1|2|3|4) ;;
> > > + *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
> > > established." +esac
> >
> > Please accept all EAPIs.
>
> These are EAPIs which are allowed throughout the tree, sorry. Feel free
> to ping Council about adding non-standard EAPIs to eclasses.
>
> > > +inherit versionator
> > > +
> > > +# @FUNCTION: boost-utils_get_best_slot
> > > +# @DESCRIPTION:
> > > +# Get newest SLOT (major version) of Boost.
> > > +boost-utils_get_best_slot() {
> > > + local pkg=dev-libs/boost
> > > + local atom=$(best_version ${pkg})
> > > + get_version_component_range 1-2 ${atom#${pkg}}
> > > +}
> > > +
> > > +# @FUNCTION: boost-utils_get_includedir
> > > +# @DESCRIPTION:
> > > +# Get correct includedir for best Boost version. Outputs the sole
> > > path +# (without -I).
> > > +boost-utils_get_includedir() {
> > > + local slot=$(boost-utils_get_best_slot)
> > > + has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
> > > +
> > > + echo -n "${EPREFIX}/usr/include/boost-${slot/./_}"
> > > +}
> >
> > There needs to be a way to specify maximal accepted slot of Boost.
> > Examples of some possibilities:
> > * BOOST_MAX_SLOT="1.49" global variable
> > * '--max 1.49' arguments for boost-utils_get_* functions
>
> I'd rather wait with that till Tiziano expresses his opinion. I think
> the policy ought to be 'always prefer newest version' but I guess
> that's hard with boost.
>
one of the points of having a slotted boost (besides solving the rebuild
when API/ABI breakages occur) is that a package may also use an older
boost slot (currently it only would make sense if we'd backport the
glibc-2.16 patches but that's a different story). So I'd prefer if we'd
have a BOOST_MAX_SLOT variable.
Re: [gentoo-dev] supporting static-libs
On Tue, 28 Aug 2012 02:15:40 +0200 hasufell wrote: > Is there a reason not to support static-libs in an ebuild if the > package supports it? > > It seems some developers don't care about this option. What's the > gentoo policy on this? Isn't this actually a bug? Some people believe that IUSE=static-libs should be always used, I think, and they consider that to be a Gentoo policy. I believe that this is pointless to add it to every single library noone will ever use as static. I do add them when it's simple (i.e. with autotools-utils) and I know the package is supposed to work when linked statically. Otherwise, I'd just wait for someone to request static-libs support, much like we don't keyword ahead. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
On Tue, 28 Aug 2012 09:43:37 +0200 hasufell wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/28/2012 06:26 AM, Arfrever Frehtes Taifersar Arahesis wrote: > > > > There needs to be a way to specify maximal accepted slot of Boost. > > Examples of some possibilities: * BOOST_MAX_SLOT="1.49" global > > variable * '--max 1.49' arguments for boost-utils_get_* functions > > > > Exactly. I don't see any reason for this eclass except this feature. > The current expected behavior of boost and build systems is that > always the latest installed will be picked. > > In fact this breaks packages in 3 of 4 cases on new boost versions. > > And while we are it it, we can punt the useless eselect It was queued for punting. That's reason for the eclass. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
On Tue, 28 Aug 2012 06:26:02 +0200
Arfrever Frehtes Taifersar Arahesis wrote:
> 2012-08-28 00:19:28 Michał Górny napisał(a):
> > --- /dev/null
> > +++ b/gx86/eclass/boost-utils.eclass
> > @@ -0,0 +1,43 @@
> > +# Copyright 1999-2012 Gentoo Foundation
> > +# Distributed under the terms of the GNU General Public License v2
> > +# $Header: $
> > +
> > +if [[ ! ${_BOOST_ECLASS} ]]; then
> > +
> > +# @ECLASS: boost-utils.eclass
> > +# @MAINTAINER:
> > +# mgo...@gentoo.org
>
> It is better to copy list of maintainers from
> gentoo-x86/dev-libs/boost/metadata.xml.
>
> > +# @BLURB: helper functions for packages using Boost C++ library
> > +# @DESCRIPTION:
> > +# Helper functions to be used when building packages using the
> > Boost C++ +# library collection.
> > +
> > +case ${EAPI:-0} in
> > + 0|1|2|3|4) ;;
> > + *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
> > established." +esac
>
> Please accept all EAPIs.
These are EAPIs which are allowed throughout the tree, sorry. Feel free
to ping Council about adding non-standard EAPIs to eclasses.
> > +inherit versionator
> > +
> > +# @FUNCTION: boost-utils_get_best_slot
> > +# @DESCRIPTION:
> > +# Get newest SLOT (major version) of Boost.
> > +boost-utils_get_best_slot() {
> > + local pkg=dev-libs/boost
> > + local atom=$(best_version ${pkg})
> > + get_version_component_range 1-2 ${atom#${pkg}}
> > +}
> > +
> > +# @FUNCTION: boost-utils_get_includedir
> > +# @DESCRIPTION:
> > +# Get correct includedir for best Boost version. Outputs the sole
> > path +# (without -I).
> > +boost-utils_get_includedir() {
> > + local slot=$(boost-utils_get_best_slot)
> > + has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
> > +
> > + echo -n "${EPREFIX}/usr/include/boost-${slot/./_}"
> > +}
>
> There needs to be a way to specify maximal accepted slot of Boost.
> Examples of some possibilities:
> * BOOST_MAX_SLOT="1.49" global variable
> * '--max 1.49' arguments for boost-utils_get_* functions
I'd rather wait with that till Tiziano expresses his opinion. I think
the policy ought to be 'always prefer newest version' but I guess
that's hard with boost.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
On Tue, 28 Aug 2012 01:03:53 +0200
"Andreas K. Huettel" wrote:
> Am Dienstag, 28. August 2012, 00:19:28 schrieb Michał Górny:
> > Right now, it just contains the function Tiziano listed in his
> > post[1]. I'd appreciate further ideas, feedback, and possibly an
> > example from someone who will actually need it.
>
> How about a function that just outputs the entire required dependency
> string? Such that we can (similar to add_kdebase_dep) write
>
> DEPEND="$(add_boost_dep)"
No, that won't work (soon). Boost is going to be split into smaller
parts, so I don't want to introduce any dependency generation API which
will have to change then.
> (Probably we may want to pass parameters here for useflags and
> version, here's the doc for kdebase_dep from kde4-functions.eclass
> (and for boost we would not need a package name):
Yes, and that makes it utterly pointless to have a function which just
converts some random magic string to random magic string + one word :P.
I'd rather give ${BOOST_PKG} to be used in *DEPEND if someone feels
that being really necessary. But as I said, it's going to be more
libraries soon.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/28/2012 06:26 AM, Arfrever Frehtes Taifersar Arahesis wrote: > > There needs to be a way to specify maximal accepted slot of Boost. > Examples of some possibilities: * BOOST_MAX_SLOT="1.49" global > variable * '--max 1.49' arguments for boost-utils_get_* functions > Exactly. I don't see any reason for this eclass except this feature. The current expected behavior of boost and build systems is that always the latest installed will be picked. In fact this breaks packages in 3 of 4 cases on new boost versions. And while we are it it, we can punt the useless eselect implementation. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQPHapAAoJEFpvPKfnPDWzAz8H/0/57b9AiYMxPM9APK5nSLCl UGuaeh+Jnz8kTIzaVE0BNP2QSNkMZqVMa9hWnHgZHG+9Ne1zgCPU2PP8hijnwWb3 JWI02t/iWfsMqY8KNMNlCbyL21r5FurIXS66KHB90bygnaZZxgGZZJ6GUNEqKH5F qPZUA++4NXnRbAU2dotaJH77v6fUXuzB/fhcrz9YmlDss+VGgxGSEGx2YJDU7WKu 4U4kawNRFxc5eJaj4ciOOeGMk4mnwq6459p9F/Kjzx3XniNCuKEA0G81Fn2GmOxe fLurBlzj2gwsg8dy+TL9VwLDwESELLZ645u3Y0SEqp34Zo+OAFdytmYg6uxP8l0= =o3qr -END PGP SIGNATURE-
