Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

[Ian Stakenvicius]

-----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 compatible with the ebuild requirements.
>>> postgres.eclass addresses this and has additional
>>> conveniences to build a dependency string and add a new user
>>> into the postgres system group.
>>>
>>> Additionally, as most of you are aware, we have a slot
>>> capable dev-db/postgresql. There is some difficulty that
>>> needed to be resolved so that extensions could also be
>>> installed into multiple slots, which is addressed by
>>> postgres-multi.eclass.
>>>
>>> I've an overlay at:
>>> https://github.com/titanofold/titanofold-gentoo-x86
>>>
>>> With the pgsql-eclass branch containing the eclass and a
>>> postgres-multi enabled PostGIS.
>>>
>>> Naturally, the eclasses work for me, so far.
>>>

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 like how the
python and ABI_* multibuilds work.  That would make the
installations as well as the dependencies be determinstic rather
than dynamic, which should support binpkgs -much- better (among
other things).

The "|| ( postgresql:${SLOT1}= postgresql:${SLOT2}= ...)" RDEPEND
that postgres.eclass works out is a little sketchy IMO,
unfortunately, as the behaviour that occurs when more than one of
those slots are installed is afaik a little unstable -- in theory,
changes (including removal) of any of the options should trigger a
rebuild but I don't know if it does, and I'm fairly certain that a
simple --unmerge doesn't trigger a rebuild.  All of that goes away
if you perform non-OR dependency via use flags.

The drawback of course is yet another USE_EXPAND, or at least a
bunch of rather long use flags, that will need setting by the user.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlaWdzAACgkQAJxUfCtlWe1k9gEAvZZ93mdUhDwTKBxcX+GcrZ5S
bwCQKIkuItSIz0221usA/1rnPt2dGWr9tGMqxekvNypx5RKnF3odSb0m1EVSnTJR
=2xB+
-----END PGP SIGNATURE-----