[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-lang/gnat-gcc/

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-lang/gnat-gcc/

[hasufell]

On 09/02/2015 02:23 PM, George Shapovalov wrote:
> commit:     12dc193801fc938bb00bfe3b6a215383fa877532
> Author:     George Shapovalov <george <AT> gentoo <DOT> org>
> AuthorDate: Mon Aug 31 12:24:34 2015 +0000
> Commit:     George Shapovalov <george <AT> gentoo <DOT> org>
> CommitDate: Wed Sep  2 12:22:13 2015 +0000
> URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=12dc1938
> 
> cleaned up ebuild to correspond to latest requirements; added EAPI in prep for gnatbuild.eclass cleanup
> 

[...]

> 
> diff --git a/dev-lang/gnat-gcc/gnat-gcc-4.6.4.ebuild b/dev-lang/gnat-gcc/gnat-gcc-4.6.4.ebuild
> index b987907..4346623 100644
> --- a/dev-lang/gnat-gcc/gnat-gcc-4.6.4.ebuild
> +++ b/dev-lang/gnat-gcc/gnat-gcc-4.6.4.ebuild
> @@ -2,6 +2,7 @@
>  # Distributed under the terms of the GNU General Public License v2
>  # $Id$
>  
> +EAPI=5
>  inherit gnatbuild
>  
>  DESCRIPTION="GNAT Ada Compiler - gcc version"
> @@ -28,7 +29,7 @@ RDEPEND=">=dev-libs/mpfr-3.1.2
>  	>=dev-libs/gmp-5.1.3
>  	>=dev-libs/mpc-1.0.1
>  	>=sys-libs/zlib-1.2
> -	>=sys-libs/ncurses-5.7"
> +	>=sys-libs/ncurses-5.7:*"
>  
>  DEPEND="${RDEPEND}
>  	doc? ( >=sys-apps/texinfo-5 )
> 

This doesn't look correct to me, unless dev-lang/gnat-gcc doesn't need
ncurses headers(?). Only sys-libs/ncurses:0 provides headers (the other
slots are for binary compatibility), so we probably want to depend on
SLOT :0. In addition, if we fix the SLOT to :0, we should do a revbump
to ensure that user VDB is updated correctly.

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-lang/gnat-gcc/

[George Shapovalov]

On Wednesday 02 September 2015 16:29:52 hasufell wrote:
> > -	>=sys-libs/ncurses-5.7"
> > +	>=sys-libs/ncurses-5.7:*"
> This doesn't look correct to me, unless dev-lang/gnat-gcc doesn't need
> ncurses headers(?). Only sys-libs/ncurses:0 provides headers (the other
> slots are for binary compatibility), so we probably want to depend on
> SLOT :0. In addition, if we fix the SLOT to :0, we should do a revbump
> to ensure that user VDB is updated correctly.
Ah, Ok, thanks for heads up on ncurses (OTOH this is a bit strange - different 
slots provide not just incompatible but drastically different contents. 
Shouldn't there be a separate -headers package then? The deps would be kind of 
more evident in such case..).
This was a part of general change to fix repoman complaints. I'll fix the 
ncurses part and do a revbump to update VDB then..

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-lang/gnat-gcc/

[hasufell]

On 09/02/2015 05:06 PM, George Shapovalov wrote:
> On Wednesday 02 September 2015 16:29:52 hasufell wrote:
>>> -	>=sys-libs/ncurses-5.7"
>>> +	>=sys-libs/ncurses-5.7:*"
>> This doesn't look correct to me, unless dev-lang/gnat-gcc doesn't need
>> ncurses headers(?). Only sys-libs/ncurses:0 provides headers (the other
>> slots are for binary compatibility), so we probably want to depend on
>> SLOT :0. In addition, if we fix the SLOT to :0, we should do a revbump
>> to ensure that user VDB is updated correctly.
> Ah, Ok, thanks for heads up on ncurses (OTOH this is a bit strange - different 
> slots provide not just incompatible but drastically different contents. 
> Shouldn't there be a separate -headers package then? The deps would be kind of 
> more evident in such case..).
> This was a part of general change to fix repoman complaints. I'll fix the 
> ncurses part and do a revbump to update VDB then..
> 
> 
> 

Well, it isn't particularly nice, because we don't have proper SLOT
descriptions (although SLOT can contain any of the characters
[A-Za-z0-9+_.-], but then I am not sure how the PM decides about the
"best" SLOT... I couldn't find a useful answer in PMS).

However, this slotting method is already used in libraries like
media-libs/libpng or dev-libs/openssl, so it seems it silently became a
standard.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-lang/gnat-gcc/

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/09/15 11:15 AM, hasufell wrote:
> On 09/02/2015 05:06 PM, George Shapovalov wrote:
>> On Wednesday 02 September 2015 16:29:52 hasufell wrote:
>>>> -	>=sys-libs/ncurses-5.7" +	>=sys-libs/ncurses-5.7:*"
>>> This doesn't look correct to me, unless dev-lang/gnat-gcc
>>> doesn't need ncurses headers(?). Only sys-libs/ncurses:0
>>> provides headers (the other slots are for binary
>>> compatibility), so we probably want to depend on SLOT :0. In
>>> addition, if we fix the SLOT to :0, we should do a revbump to
>>> ensure that user VDB is updated correctly.
>> Ah, Ok, thanks for heads up on ncurses (OTOH this is a bit
>> strange - different slots provide not just incompatible but
>> drastically different contents. Shouldn't there be a separate
>> -headers package then? The deps would be kind of more evident
>> in such case..). This was a part of general change to fix
>> repoman complaints. I'll fix the ncurses part and do a revbump
>> to update VDB then..
>> 
>> 
>> 
> 
> Well, it isn't particularly nice, because we don't have proper
> SLOT descriptions (although SLOT can contain any of the
> characters [A-Za-z0-9+_.-], but then I am not sure how the PM
> decides about the "best" SLOT... I couldn't find a useful answer
> in PMS).
> 
> However, this slotting method is already used in libraries like 
> media-libs/libpng or dev-libs/openssl, so it seems it silently
> became a standard.
> 


There's no "best" slot, slots aren't used the same as versions --
they either match or differ.  The slot that's preferred (in portage
at least, i expect other PMs too) is the SLOT of the most recent
version of the package that's emerge'able.

In terms of libraries in general, although the SLOT=0 for full
package version / SLOT=somethingelse for binary-only stuff is a bit
of a convention, you need to check what slotting actually means for
every dependency your package depends on because each one will
differ.  For instance, sci-libs/opencascade installs all versions in
their own specific slot, headers and all.  The choice generally
comes down to what the maintainer of the library package decides to do
.




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

iF4EAREIAAYFAlXnIUEACgkQAJxUfCtlWe2TMQEAqwtrleALZNxUeBJzxtilTY19
6+ndXbA0GeY70HpWvdQA/jEB87y+zQoP7J/HMXOZRMHa5bRfwAyZLO8t5VloScyd
=U6d6
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-lang/gnat-gcc/

[hasufell]

On 09/02/2015 06:18 PM, Ian Stakenvicius wrote:
> 
> There's no "best" slot, slots aren't used the same as versions --
> they either match or differ.  The slot that's preferred (in portage
> at least, i expect other PMs too) is the SLOT of the most recent
> version of the package that's emerge'able.
> 

Absolutely correct. I must have been confused, because some PMs actually
do use the term "best slot".

> In terms of libraries in general, although the SLOT=0 for full
> package version / SLOT=somethingelse for binary-only stuff is a bit
> of a convention, you need to check what slotting actually means for
> every dependency your package depends on because each one will
> differ.  For instance, sci-libs/opencascade installs all versions in
> their own specific slot, headers and all.  The choice generally
> comes down to what the maintainer of the library package decides to do
> .
> 

This is another case where I feel we need better metadata support (or at
least some documentation policy/standard, so developers don't go into
pitfalls). With the rise of SUBSLOTs this becomes even more a problem,
because they also can mean a few different things.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-lang/gnat-gcc/

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/09/15 12:31 PM, hasufell wrote:
>> In terms of libraries in general, although the SLOT=0 for full 
>> package version / SLOT=somethingelse for binary-only stuff is a
>> bit of a convention, you need to check what slotting actually
>> means for every dependency your package depends on because each
>> one will differ.  For instance, sci-libs/opencascade installs
>> all versions in their own specific slot, headers and all.  The
>> choice generally comes down to what the maintainer of the
>> library package decides to do .
>> 
> 
> This is another case where I feel we need better metadata support
> (or at least some documentation policy/standard, so developers
> don't go into pitfalls). With the rise of SUBSLOTs this becomes
> even more a problem, because they also can mean a few different
> things.
> 

Also true..  In theory, subslot changes should just mean an ABI
change that will require a rebuild, but in practice things are a lot
more complicated.  It wouldn't hurt, even in terms of maintainer(s)
keeping track within the package itself, if there was metadata about
this filed somewhere.




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

iF4EAREIAAYFAlXnL7UACgkQAJxUfCtlWe1XwwD/TVIFk6dJSYNtsZROduNxCWIN
2F6Al4Pca7rpqyBQ0WcA/0svJX65zA29gucf+Zf6pb9BPbQF/KtyR2VPuXQRj7tE
=Na5Z
-----END PGP SIGNATURE-----