On 2016-01-25 10:31, Ian Stakenvicius wrote:
> On 23/01/16 10:51 AM, Ian Stakenvicius wrote:
> >> On Jan 22, 2016, at 3:11 PM, Aaron W. Swenson
> >> wrote:
> >>
> >> I would like some feedback on the documentation/comments in
> >> the eclass. I'm certain it could be improved. Though, if you
> >>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 23/01/16 10:51 AM, Ian Stakenvicius wrote:
>
>
>> On Jan 22, 2016, at 3:11 PM, Aaron W. Swenson
>> wrote:
>>
>>
>> I would like some feedback on the documentation/comments in
>> the eclass. I'm certain it could be improved. Though, if you
>>
On 2016-01-24 18:44, Michael Orlitzky wrote:
> On 01/24/2016 06:29 PM, Aaron W. Swenson wrote:
> > Okay, provided that the new USE_EXPAND is okay for POSTGRES_TARGETS,
> > attached are the eclasses that I'll commit to the tree.
> >
>
> > case ${EAPI:-0} in
> > 0|1|2|3|4) die "postgres-multi.ecl
On 01/24/2016 06:29 PM, Aaron W. Swenson wrote:
> Okay, provided that the new USE_EXPAND is okay for POSTGRES_TARGETS,
> attached are the eclasses that I'll commit to the tree.
>
> case ${EAPI:-0} in
> 0|1|2|3|4) die "postgres-multi.eclass requires EAPI 5 or higher" ;;
> *) ;;
> esac
Does th
Okay, provided that the new USE_EXPAND is okay for POSTGRES_TARGETS,
attached are the eclasses that I'll commit to the tree.
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$
inherit multibuild postgres
EXPORT_FUNCTIONS pkg_setup src_
> On Jan 22, 2016, at 3:11 PM, Aaron W. Swenson wrote:
>
>
> I would like some feedback on the documentation/comments in the
> eclass. I'm certain it could be improved. Though, if you were able to
> follow them (not a slight, just you were the first to follow them), I
> might have done good en
On 2016-01-22 11:51, Ian Stakenvicius wrote:
> The eclasses look good to go for me -- i've built an ebuild for pl/R
> using them and it works as expected (and it's nice to not have to
> define PG_CONFIG et. al. myself too).
>
> Can the eclasses be migrated to the tree soon?
I wanted to test the e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The eclasses look good to go for me -- i've built an ebuild for pl/R
using them and it works as expected (and it's nice to not have to
define PG_CONFIG et. al. myself too).
Can the eclasses be migrated to the tree soon?
Also of note, it will be imp
On 2016-01-15 12:43, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 15/01/16 11:43 AM, Aaron W. Swenson wrote:
> > On 2016-01-13 11:11, Ian Stakenvicius wrote:
> >> The work looks really good, but I noticed that postgres-multi
> >> determins the variants to bui
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/01/16 12:43 PM, Ian Stakenvicius wrote:
> On 15/01/16 11:43 AM, Aaron W. Swenson wrote:
>> On 2016-01-13 11:11, Ian Stakenvicius wrote:
>>> The work looks really good, but I noticed that postgres-multi
>>> determins the variants to build again
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/01/16 11:43 AM, Aaron W. Swenson wrote:
> On 2016-01-13 11:11, Ian Stakenvicius wrote:
>> The work looks really good, but I noticed that postgres-multi
>> determins the variants to build against based on what's
>> installed on disk via checkin
On 2016-01-13 11:11, Ian Stakenvicius wrote:
> The work looks really good, but I noticed that postgres-multi
> determins the variants to build against based on what's installed on
> disk via checking eselect.. I think it'd likely be better to
> instead have proper dependencies based on USE, much l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
>> On 12.01.2016 20:22, Aaron W. Swenson wrote:
>>> There are several ebuilds that repeat the same checks and
>>> need to perform the same duties when it comes to working with
>>> PostgreSQL. For example, making sure the users' currently
>>> slot is
On 2016-01-12 21:57, Manuel Rüger wrote:
> On 12.01.2016 20:22, Aaron W. Swenson wrote:
> > There are several ebuilds that repeat the same checks and need to
> > perform the same duties when it comes to working with PostgreSQL. For
> > example, making sure the users' currently slot is compatible wi
On 12.01.2016 20:22, Aaron W. Swenson wrote:
> There are several ebuilds that repeat the same checks and need to
> perform the same duties when it comes to working with PostgreSQL. For
> example, making sure the users' currently slot is compatible with the
> ebuild requirements. postgres.eclass add
There are several ebuilds that repeat the same checks and need to
perform the same duties when it comes to working with PostgreSQL. For
example, making sure the users' currently slot is compatible with the
ebuild requirements. postgres.eclass addresses this and has
additional conveniences to build
16 matches
Mail list logo
