[gentoo-dev] prune_libtool_files() and pkg-config dependency

[gentoo-dev] prune_libtool_files() and pkg-config dependency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

Hello, fellow developers.

I'd like to note that the prune_libtool_files() in eutils.eclass has
a pretty specific dependency on pkg-config. Whenever it is used
in an ebuild, it should depend on virtual/pkgconfig if all
of the following conditions are met:

1. The ebuild installs at least a single static library with
a corresponding .la file,

2. the .la files has no 'shouldnotlink=yes' (i.e. is not a plugin),

3. the .la file has non-empty 'dependency_libs' and/or
'inherited_linker_flags',

4. the '--all' option is not being used.

In other words, pkg-config is only used when no other criteria allows
it to classify the particular .la file as suitable for removal or not.
Sadly, it's rather, ehm, unfriendly to ebuild developers who obviously
don't even read the relevant part.

Do you have any ideas how we can improve that?

One thing that comes into my mind is finally making pkgconfig
a required, implicit part of toolchain (or @system). Since we have
pkgconf now, this is more feasible than before.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Mike Frysinger]

On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote:
> In other words, pkg-config is only used when no other criteria allows
> it to classify the particular .la file as suitable for removal or not.
> Sadly, it's rather, ehm, unfriendly to ebuild developers who obviously
> don't even read the relevant part.
>
> Do you have any ideas how we can improve that?

before the func executes pkg-config, run `has virtual/pkgconfig
${DEPEND}` and spit an eqawarn if it's not found

> One thing that comes into my mind is finally making pkgconfig
> a required, implicit part of toolchain (or @system). Since we have
> pkgconf now, this is more feasible than before.

i don't think making it part of the toolchain makes sense.  i'd rather
not add it to @system simply to keep a few packages from sometimes
failing.
-mike

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]

On Wed, 29 Aug 2012 17:50:16 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote:
> > In other words, pkg-config is only used when no other criteria
> > allows it to classify the particular .la file as suitable for
> > removal or not. Sadly, it's rather, ehm, unfriendly to ebuild
> > developers who obviously don't even read the relevant part.
> >
> > Do you have any ideas how we can improve that?
> 
> before the func executes pkg-config, run `has virtual/pkgconfig
> ${DEPEND}` and spit an eqawarn if it's not found

Ciaran will shot at me for doing that.

> > One thing that comes into my mind is finally making pkgconfig
> > a required, implicit part of toolchain (or @system). Since we have
> > pkgconf now, this is more feasible than before.
> 
> i don't think making it part of the toolchain makes sense.  i'd rather
> not add it to @system simply to keep a few packages from sometimes
> failing.

I'd add it to @system because a lot of packages actually need to DEPEND
on pkgconfig because they use libraries using .pc files. And the number
is going to increase, hopefully.

Also, some people are probably going to try to get some pkgconf support
directly into gcc, in form of '-something libfoo' to make it grab
everything magically, I think.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Mike Frysinger]

On Wed, Aug 29, 2012 at 6:02 PM, Michał Górny wrote:
> On Wed, 29 Aug 2012 17:50:16 -0400 Mike Frysinger wrote:
>> On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote:
>> > In other words, pkg-config is only used when no other criteria
>> > allows it to classify the particular .la file as suitable for
>> > removal or not. Sadly, it's rather, ehm, unfriendly to ebuild
>> > developers who obviously don't even read the relevant part.
>> >
>> > Do you have any ideas how we can improve that?
>>
>> before the func executes pkg-config, run `has virtual/pkgconfig
>> ${DEPEND}` and spit an eqawarn if it's not found
>
> Ciaran will shot at me for doing that.

it isn't violating anything and can find real bugs.  i don't see a problem here.

>> > One thing that comes into my mind is finally making pkgconfig
>> > a required, implicit part of toolchain (or @system). Since we have
>> > pkgconf now, this is more feasible than before.
>>
>> i don't think making it part of the toolchain makes sense.  i'd rather
>> not add it to @system simply to keep a few packages from sometimes
>> failing.
>
> I'd add it to @system because a lot of packages actually need to DEPEND
> on pkgconfig because they use libraries using .pc files. And the number
> is going to increase, hopefully.

sure, but keeping things in @system doesn't make much sense:
 - there's a penalty (as noted in old threads)
 - it isn't actually required at runtime, so it's bloat on reduced systems

> Also, some people are probably going to try to get some pkgconf support
> directly into gcc, in form of '-something libfoo' to make it grab
> everything magically, I think.

if gcc itself runs `pkg-config` to look up libraries from other
packages, then we can add it to DEPEND, but if that's not currently
the case, the dependency doesn't make sense.
-mike

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

On 29/08/2012 15:02, Michał Górny wrote:
> I'd add it to @system because a lot of packages actually need to DEPEND
> on pkgconfig because they use libraries using .pc files. And the number
> is going to increase, hopefully.

And yet it shouldn't be part of system because it's not necessary to run
a system, let alone a POSIX system.

> Also, some people are probably going to try to get some pkgconf support
> directly into gcc, in form of '-something libfoo' to make it grab
> everything magically, I think.

You have a future as a comedian.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 554 bytes --]

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1876 bytes --]

On Wed, 29 Aug 2012 18:05:19 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On Wed, Aug 29, 2012 at 6:02 PM, Michał Górny wrote:
> > On Wed, 29 Aug 2012 17:50:16 -0400 Mike Frysinger wrote:
> >> On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote:
> >> > In other words, pkg-config is only used when no other criteria
> >> > allows it to classify the particular .la file as suitable for
> >> > removal or not. Sadly, it's rather, ehm, unfriendly to ebuild
> >> > developers who obviously don't even read the relevant part.
> >> >
> >> > Do you have any ideas how we can improve that?
> >>
> >> before the func executes pkg-config, run `has virtual/pkgconfig
> >> ${DEPEND}` and spit an eqawarn if it's not found
> >
> > Ciaran will shot at me for doing that.
> 
> it isn't violating anything and can find real bugs.  i don't see a
> problem here.

It is violating the Holy PMS.

> >> > One thing that comes into my mind is finally making pkgconfig
> >> > a required, implicit part of toolchain (or @system). Since we
> >> > have pkgconf now, this is more feasible than before.
> >>
> >> i don't think making it part of the toolchain makes sense.  i'd
> >> rather not add it to @system simply to keep a few packages from
> >> sometimes failing.
> >
> > I'd add it to @system because a lot of packages actually need to
> > DEPEND on pkgconfig because they use libraries using .pc files. And
> > the number is going to increase, hopefully.
> 
> sure, but keeping things in @system doesn't make much sense:
>  - there's a penalty (as noted in old threads)
>  - it isn't actually required at runtime, so it's bloat on reduced
> systems

I think it's practically the same as compiler.

Also, a quick look at !ddep shows over 7000 reverse dependencies. That
looks like a bigger penalty to me.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

On Wed, 29 Aug 2012 15:06:16 -0700
Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:

> On 29/08/2012 15:02, Michał Górny wrote:
> > Also, some people are probably going to try to get some pkgconf
> > support directly into gcc, in form of '-something libfoo' to make
> > it grab everything magically, I think.
> 
> You have a future as a comedian.

Sir, you are going too far.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

On 29/08/2012 15:16, Michał Górny wrote:
>>> > > Also, some people are probably going to try to get some pkgconf
>>> > > support directly into gcc, in form of '-something libfoo' to make
>>> > > it grab everything magically, I think.
>> > 
>> > You have a future as a comedian.
> Sir, you are going too far.

I'm just saying that relying on something like that is a ludicrous notion.

Okay so somebody might actually try to do that, not going to debate that
— people have been out of their mind before.

But developers actually relying on it? I find it very hard, as that
basically means you're introducing build systems that only ever work on
a theoretical GCC 4.8 _and nothing else_.

So can you see what makes me laugh in your statement?

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 554 bytes --]

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Mike Frysinger]

On Wed, Aug 29, 2012 at 6:14 PM, Michał Górny wrote:
> On Wed, 29 Aug 2012 18:05:19 -0400 Mike Frysinger wrote:
>> On Wed, Aug 29, 2012 at 6:02 PM, Michał Górny wrote:
>> > On Wed, 29 Aug 2012 17:50:16 -0400 Mike Frysinger wrote:
>> >> On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote:
>> >> > In other words, pkg-config is only used when no other criteria
>> >> > allows it to classify the particular .la file as suitable for
>> >> > removal or not. Sadly, it's rather, ehm, unfriendly to ebuild
>> >> > developers who obviously don't even read the relevant part.
>> >> >
>> >> > Do you have any ideas how we can improve that?
>> >>
>> >> before the func executes pkg-config, run `has virtual/pkgconfig
>> >> ${DEPEND}` and spit an eqawarn if it's not found
>> >
>> > Ciaran will shot at me for doing that.
>>
>> it isn't violating anything and can find real bugs.  i don't see a
>> problem here.
>
> It is violating the Holy PMS.

does it actually ?  are DEPEND variables not allowed to be expanded in
pkg_* src_* funcs ?

we could probably add a similar check to autotools.eclass: grep for
PKG_PROG_PKG_CONFIG and check ${DEPEND}

>> >> > One thing that comes into my mind is finally making pkgconfig
>> >> > a required, implicit part of toolchain (or @system). Since we
>> >> > have pkgconf now, this is more feasible than before.
>> >>
>> >> i don't think making it part of the toolchain makes sense.  i'd
>> >> rather not add it to @system simply to keep a few packages from
>> >> sometimes failing.
>> >
>> > I'd add it to @system because a lot of packages actually need to
>> > DEPEND on pkgconfig because they use libraries using .pc files. And
>> > the number is going to increase, hopefully.
>>
>> sure, but keeping things in @system doesn't make much sense:
>>  - there's a penalty (as noted in old threads)
>>  - it isn't actually required at runtime, so it's bloat on reduced
>> systems
>
> I think it's practically the same as compiler.

that isn't a bad view point, but for the purposes of this discussion,
i don't think it's relevant :)

> Also, a quick look at !ddep shows over 7000 reverse dependencies. That
> looks like a bigger penalty to me.

if we had a @build-system, you might be able to convince me.  but we
don't.  so the number of packages here doesn't matter as it's an
invalid implicit RDEPEND.
-mike

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Alexandre Rostovtsev]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

On Thu, 2012-08-30 at 00:02 +0200, Michał Górny wrote:
> On Wed, 29 Aug 2012 17:50:16 -0400
> Mike Frysinger <vapier@gentoo.org> wrote:
> 
> > On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote:
> > > In other words, pkg-config is only used when no other criteria
> > > allows it to classify the particular .la file as suitable for
> > > removal or not. Sadly, it's rather, ehm, unfriendly to ebuild
> > > developers who obviously don't even read the relevant part.
> > >
> > > Do you have any ideas how we can improve that?
> > 
> > before the func executes pkg-config, run `has virtual/pkgconfig
> > ${DEPEND}` and spit an eqawarn if it's not found
> 
> Ciaran will shot at me for doing that.

Ciaran only shoots at people for checking $DEPEND at inherit time. I
think that checking $DEPEND in prune_libtool_files, which is called from
src_install, shouldn't be a problem.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

On Wed, 29 Aug 2012 18:18:20 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> does it actually ?  are DEPEND variables not allowed to be expanded in
> pkg_* src_* funcs ?

Nope. We don't guarantee that the metadata variable gets exported back
to the ebuild environment.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

On Wed, 29 Aug 2012 18:24:45 -0400
Alexandre Rostovtsev <tetromino@gentoo.org> wrote:
> Ciaran only shoots at people for checking $DEPEND at inherit time. I
> think that checking $DEPEND in prune_libtool_files, which is called
> from src_install, shouldn't be a problem.

Naah, I shout at people for thinking that the fancy eclass-mangled
variables will have their mangled values visible within the environment.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Mike Frysinger]

On Wed, Aug 29, 2012 at 6:37 PM, Ciaran McCreesh wrote:
> On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
>> does it actually ?  are DEPEND variables not allowed to be expanded in
>> pkg_* src_* funcs ?
>
> Nope. We don't guarantee that the metadata variable gets exported back
> to the ebuild environment.

it's not a requirement, so if the PM doesn't export it, that's not a problem.

if [[ ${DEPEND+set} == "set" ]] && ! has virtual/pkgconifg ${DEPEND} ; then
  eqawarn "..."
fi
-mike

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Alec Warner]

On Thu, Aug 30, 2012 at 1:12 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Wed, Aug 29, 2012 at 6:37 PM, Ciaran McCreesh wrote:
>> On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
>>> does it actually ?  are DEPEND variables not allowed to be expanded in
>>> pkg_* src_* funcs ?
>>
>> Nope. We don't guarantee that the metadata variable gets exported back
>> to the ebuild environment.
>
> it's not a requirement, so if the PM doesn't export it, that's not a problem.
>
> if [[ ${DEPEND+set} == "set" ]] && ! has virtual/pkgconifg ${DEPEND} ; then
>   eqawarn "..."
> fi
> -mike
>

Shut up and take my money?

-A

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

On Wed, 29 Aug 2012 19:12:01 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On Wed, Aug 29, 2012 at 6:37 PM, Ciaran McCreesh wrote:
> > On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
> >> does it actually ?  are DEPEND variables not allowed to be
> >> expanded in pkg_* src_* funcs ?
> >
> > Nope. We don't guarantee that the metadata variable gets exported
> > back to the ebuild environment.
> 
> it's not a requirement, so if the PM doesn't export it, that's not a
> problem.
> 
> if [[ ${DEPEND+set} == "set" ]] && ! has virtual/pkgconifg
> ${DEPEND} ; then eqawarn "..."
> fi

It may have a semi-random value, I think. Then you could warn for
perfectly valid ebuilds.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

On Wed, 29 Aug 2012 15:17:48 -0700
Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:

> On 29/08/2012 15:16, Michał Górny wrote:
> >>> > > Also, some people are probably going to try to get some
> >>> > > pkgconf support directly into gcc, in form of '-something
> >>> > > libfoo' to make it grab everything magically, I think.
> >> > 
> >> > You have a future as a comedian.
> > Sir, you are going too far.
> 
> I'm just saying that relying on something like that is a ludicrous
> notion.
> 
> Okay so somebody might actually try to do that, not going to debate
> that — people have been out of their mind before.
> 
> But developers actually relying on it? I find it very hard, as that
> basically means you're introducing build systems that only ever work
> on a theoretical GCC 4.8 _and nothing else_.
> 
> So can you see what makes me laugh in your statement?

So you haven't seen GNU Makefiles, do you?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Mike Frysinger]

On Thu, Aug 30, 2012 at 3:41 AM, Michał Górny wrote:
> On Wed, 29 Aug 2012 19:12:01 -0400 Mike Frysinger wrote:
>> On Wed, Aug 29, 2012 at 6:37 PM, Ciaran McCreesh wrote:
>> > On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
>> >> does it actually ?  are DEPEND variables not allowed to be
>> >> expanded in pkg_* src_* funcs ?
>> >
>> > Nope. We don't guarantee that the metadata variable gets exported
>> > back to the ebuild environment.
>>
>> it's not a requirement, so if the PM doesn't export it, that's not a
>> problem.
>>
>> if [[ ${DEPEND+set} == "set" ]] && ! has virtual/pkgconifg
>> ${DEPEND} ; then eqawarn "..."
>> fi
>
> It may have a semi-random value, I think. Then you could warn for
> perfectly valid ebuilds.

in my quick test it seemed to have a fine value.  let's deploy it and
see what kind of reports we get back.

you could also make it do:
    libs=$("${pkgconf}" --libs "${tf}") || die
-mike

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2473 bytes --]

On Wed, 29 Aug 2012 18:18:20 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On Wed, Aug 29, 2012 at 6:14 PM, Michał Górny wrote:
> > On Wed, 29 Aug 2012 18:05:19 -0400 Mike Frysinger wrote:
> >> On Wed, Aug 29, 2012 at 6:02 PM, Michał Górny wrote:
> >> > On Wed, 29 Aug 2012 17:50:16 -0400 Mike Frysinger wrote:
> >> >> On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote:
> >> >> > In other words, pkg-config is only used when no other criteria
> >> >> > allows it to classify the particular .la file as suitable for
> >> >> > removal or not. Sadly, it's rather, ehm, unfriendly to ebuild
> >> >> > developers who obviously don't even read the relevant part.
> >> >> >
> >> >> > Do you have any ideas how we can improve that?
> >> >>
> >> >> before the func executes pkg-config, run `has virtual/pkgconfig
> >> >> ${DEPEND}` and spit an eqawarn if it's not found
> >> >
> >> > Ciaran will shot at me for doing that.
> >>
> >> it isn't violating anything and can find real bugs.  i don't see a
> >> problem here.
> >
> > It is violating the Holy PMS.
> 
> does it actually ?  are DEPEND variables not allowed to be expanded in
> pkg_* src_* funcs ?
> 
> we could probably add a similar check to autotools.eclass: grep for
> PKG_PROG_PKG_CONFIG and check ${DEPEND}
> 
> >> >> > One thing that comes into my mind is finally making pkgconfig
> >> >> > a required, implicit part of toolchain (or @system). Since we
> >> >> > have pkgconf now, this is more feasible than before.
> >> >>
> >> >> i don't think making it part of the toolchain makes sense.  i'd
> >> >> rather not add it to @system simply to keep a few packages from
> >> >> sometimes failing.
> >> >
> >> > I'd add it to @system because a lot of packages actually need to
> >> > DEPEND on pkgconfig because they use libraries using .pc files.
> >> > And the number is going to increase, hopefully.
> >>
> >> sure, but keeping things in @system doesn't make much sense:
> >>  - there's a penalty (as noted in old threads)
> >>  - it isn't actually required at runtime, so it's bloat on reduced
> >> systems
> >
> > I think it's practically the same as compiler.
> 
> that isn't a bad view point, but for the purposes of this discussion,
> i don't think it's relevant :)

Will it be a better view point if I opened a separate discussion about
putting pkg-config in @system? It could get more attention probably.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] prune_libtool_files() and pkg-config dependency

[Mike Frysinger]

On Thu, Aug 30, 2012 at 6:39 PM, Michał Górny wrote:
> On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
>> On Wed, Aug 29, 2012 at 6:14 PM, Michał Górny wrote:
>> > On Wed, 29 Aug 2012 18:05:19 -0400 Mike Frysinger wrote:
>> >> On Wed, Aug 29, 2012 at 6:02 PM, Michał Górny wrote:
>> >> > On Wed, 29 Aug 2012 17:50:16 -0400 Mike Frysinger wrote:
>> >> >> On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote:
>> >> >> > One thing that comes into my mind is finally making pkgconfig
>> >> >> > a required, implicit part of toolchain (or @system). Since we
>> >> >> > have pkgconf now, this is more feasible than before.
>> >> >>
>> >> >> i don't think making it part of the toolchain makes sense.  i'd
>> >> >> rather not add it to @system simply to keep a few packages from
>> >> >> sometimes failing.
>> >> >
>> >> > I'd add it to @system because a lot of packages actually need to
>> >> > DEPEND on pkgconfig because they use libraries using .pc files.
>> >> > And the number is going to increase, hopefully.
>> >>
>> >> sure, but keeping things in @system doesn't make much sense:
>> >>  - there's a penalty (as noted in old threads)
>> >>  - it isn't actually required at runtime, so it's bloat on reduced
>> >> systems
>> >
>> > I think it's practically the same as compiler.
>>
>> that isn't a bad view point, but for the purposes of this discussion,
>> i don't think it's relevant :)
>
> Will it be a better view point if I opened a separate discussion about
> putting pkg-config in @system? It could get more attention probably.

my answer would still be a very strong no
-mike

[gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Duncan]

Mike Frysinger posted on Thu, 30 Aug 2012 19:46:21 -0400 as excerpted:

> On Thu, Aug 30, 2012 at 6:39 PM, Michał Górny wrote:
>> On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
>>> On Wed, Aug 29, 2012 at 6:14 PM, Michał Górny wrote:
>>> > On Wed, 29 Aug 2012 18:05:19 -0400 Mike Frysinger wrote:
>>> >>
>>> >> keeping things in @system doesn't make much sense:
>>> >>  - there's a penalty (as noted in old threads)
>>> >>  - it isn't actually required at runtime, so it's bloat on reduced
>>> >> systems
>>> >
>>> > I think it's practically the same as compiler.
>>>
>>> that isn't a bad view point, but for the purposes of this discussion,
>>> i don't think it's relevant :)
>>
>> Will it be a better view point if I opened a separate discussion about
>> putting pkg-config in @system? It could get more attention probably.
> 
> my answer would still be a very strong no

Agreed.

Various people have in fact expressed a desire to REDUCE the number of 
packages in @system, for various reasons including both the parallel 
merge penalty and the bloat on reduced systems.  In practice, there's not 
a lot of positive movement on actually reducing @system, but at minimum, 
unless there's *NO* other choice and in this case there clearly is, we 
shouldn't be ADDING packages to @system.

For that reason, while I do see the reason why some would like pkg-config 
added to @system, the whole idea's pretty much a non-starter, as it WILL 
get a lot of push-back.  In theory it /might/ be forceable, but I just 
don't see how the cost, political, in time to push thru, and technical 
(given the technical reasons listed above), makes it worth pursuing in 
the slightest.  It's just not worth going there.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2003 bytes --]

On Fri, 31 Aug 2012 00:12:53 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Mike Frysinger posted on Thu, 30 Aug 2012 19:46:21 -0400 as excerpted:
> 
> > On Thu, Aug 30, 2012 at 6:39 PM, Michał Górny wrote:
> >> On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
> >>> On Wed, Aug 29, 2012 at 6:14 PM, Michał Górny wrote:
> >>> > On Wed, 29 Aug 2012 18:05:19 -0400 Mike Frysinger wrote:
> >>> >>
> >>> >> keeping things in @system doesn't make much sense:
> >>> >>  - there's a penalty (as noted in old threads)
> >>> >>  - it isn't actually required at runtime, so it's bloat on
> >>> >> reduced systems
> >>> >
> >>> > I think it's practically the same as compiler.
> >>>
> >>> that isn't a bad view point, but for the purposes of this
> >>> discussion, i don't think it's relevant :)
> >>
> >> Will it be a better view point if I opened a separate discussion
> >> about putting pkg-config in @system? It could get more attention
> >> probably.
> > 
> > my answer would still be a very strong no
> 
> Agreed.
> 
> Various people have in fact expressed a desire to REDUCE the number
> of packages in @system, for various reasons including both the
> parallel merge penalty and the bloat on reduced systems.  In
> practice, there's not a lot of positive movement on actually reducing
> @system, but at minimum, unless there's *NO* other choice and in this
> case there clearly is, we shouldn't be ADDING packages to @system.
> 
> For that reason, while I do see the reason why some would like
> pkg-config added to @system, the whole idea's pretty much a
> non-starter, as it WILL get a lot of push-back.  In theory it /might/
> be forceable, but I just don't see how the cost, political, in time
> to push thru, and technical (given the technical reasons listed
> above), makes it worth pursuing in the slightest.  It's just not
> worth going there.

But you're aware that cost of pkgconf is very little?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

[gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Duncan]

Michał Górny posted on Fri, 31 Aug 2012 10:01:09 +0200 as excerpted:

> On Fri, 31 Aug 2012 00:12:53 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> Various people have in fact expressed a desire to REDUCE the number of
>> packages in @system, for various reasons including both the parallel
>> merge penalty and the bloat on reduced systems.  In practice, there's
>> not a lot of positive movement on actually reducing @system, but at
>> minimum, unless there's *NO* other choice and in this case there
>> clearly is, we shouldn't be ADDING packages to @system.
>> 
>> For that reason, while I do see the reason why some would like
>> pkg-config added to @system, the whole idea's pretty much a
>> non-starter

> But you're aware that cost of pkgconf is very little?

Not really, when it's a step in the opposite direction from an intended 
goal.  The first step toward any goal is to stop going backward, and 
that's exactly what this would be.  We need a smaller @system, not a 
larger one, and while the add would be easy, undoing it years later when 
it's yet another bit of the tangled web woven, would be *MUCH* more 
difficult.  Just don't do it; don't go backward; don't add to the problem 
instead of reducing it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]

On Fri, 31 Aug 2012 10:06:06 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Michał Górny posted on Fri, 31 Aug 2012 10:01:09 +0200 as excerpted:
> 
> > On Fri, 31 Aug 2012 00:12:53 +0000 (UTC)
> > Duncan <1i5t5.duncan@cox.net> wrote:
> > 
> >> Various people have in fact expressed a desire to REDUCE the
> >> number of packages in @system, for various reasons including both
> >> the parallel merge penalty and the bloat on reduced systems.  In
> >> practice, there's not a lot of positive movement on actually
> >> reducing @system, but at minimum, unless there's *NO* other choice
> >> and in this case there clearly is, we shouldn't be ADDING packages
> >> to @system.
> >> 
> >> For that reason, while I do see the reason why some would like
> >> pkg-config added to @system, the whole idea's pretty much a
> >> non-starter
> 
> > But you're aware that cost of pkgconf is very little?
> 
> Not really, when it's a step in the opposite direction from an
> intended goal.  The first step toward any goal is to stop going
> backward, and that's exactly what this would be.  We need a smaller
> @system, not a larger one, and while the add would be easy, undoing
> it years later when it's yet another bit of the tangled web woven,
> would be *MUCH* more difficult.  Just don't do it; don't go backward;
> don't add to the problem instead of reducing it.

So please introduce virtual/compiler, virtual/linker,
virtual/posix-system, virtual/sratatata and add them to DEPEND of every
single ebuild.

I believe that the more important direction here is to make development
*easier*, not harder. Adding the same DEPENDs over and over again to
every single package is at least frustrating. Similarly frustrating
would be if those 'reduced systems' had to rebuild gcc every time they
wanted to compile something... oh wait, they would have to bootstrap it
every time.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Rich Freeman]

On Fri, Aug 31, 2012 at 6:42 AM, Michał Górny <mgorny@gentoo.org> wrote:
>
> So please introduce virtual/compiler, virtual/linker,
> virtual/posix-system, virtual/sratatata and add them to DEPEND of every
> single ebuild.

Every ebuild doesn't need all of those - that is the whole point.  As
Duncan already pointed out, reducing @system is a goal, but it doesn't
mean that we need to get there overnight.  However, we'll never get
there if we keep going backwards.

>
> I believe that the more important direction here is to make development
> *easier*, not harder. Adding the same DEPENDs over and over again to
> every single package is at least frustrating.

This isn't needed by every single package either.  I'm all for tools
that help automate DEPEND population, and I'm fine with having an
ebuild template that includes "gotcha" depends pre-populated so that
devs give them consideration (and deleting lines is easier than adding
them).

> Similarly frustrating
> would be if those 'reduced systems' had to rebuild gcc every time they
> wanted to compile something... oh wait, they would have to bootstrap it
> every time.
>

I would think that somebody running a reduced system would be likely
to be installing binary packages, or use a binary package of gcc, etc.
 Presumably they knew what they're getting into and for whatever
reason the balance was considered acceptable for them.  I would think
that the sorts of people who would run reduced systems would probably
not be updating them frequently anyway.

There are also other benefits of reduced @system besides running a
reduced system.

Rich

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Alexis Ballier]

On Fri, 31 Aug 2012 12:42:10 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Fri, 31 Aug 2012 10:06:06 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> 
> > Michał Górny posted on Fri, 31 Aug 2012 10:01:09 +0200 as excerpted:
> > 
> > > On Fri, 31 Aug 2012 00:12:53 +0000 (UTC)
> > > Duncan <1i5t5.duncan@cox.net> wrote:
> > > 
> > >> Various people have in fact expressed a desire to REDUCE the
> > >> number of packages in @system, for various reasons including both
> > >> the parallel merge penalty and the bloat on reduced systems.  In
> > >> practice, there's not a lot of positive movement on actually
> > >> reducing @system, but at minimum, unless there's *NO* other
> > >> choice and in this case there clearly is, we shouldn't be ADDING
> > >> packages to @system.
> > >> 
> > >> For that reason, while I do see the reason why some would like
> > >> pkg-config added to @system, the whole idea's pretty much a
> > >> non-starter
> > 
> > > But you're aware that cost of pkgconf is very little?
> > 
> > Not really, when it's a step in the opposite direction from an
> > intended goal.  The first step toward any goal is to stop going
> > backward, and that's exactly what this would be.  We need a smaller
> > @system, not a larger one, and while the add would be easy, undoing
> > it years later when it's yet another bit of the tangled web woven,
> > would be *MUCH* more difficult.  Just don't do it; don't go
> > backward; don't add to the problem instead of reducing it.
> 
> So please introduce virtual/compiler, virtual/linker,
> virtual/posix-system, virtual/sratatata and add them to DEPEND of
> every single ebuild.
> 
> I believe that the more important direction here is to make
> development *easier*, not harder. Adding the same DEPENDs over and
> over again to every single package is at least frustrating. Similarly
> frustrating would be if those 'reduced systems' had to rebuild gcc
> every time they wanted to compile something... oh wait, they would
> have to bootstrap it every time.
> 

you would achieve it better by adding pkgconfig to DEPEND in
eutils.eclass than putting it in @system since in the latter case it
would also be a RDEPEND of everything basically

this doesnt really compare to gcc since its a RDEPEND for everything c++
and maybe more (i didnt check when libgcc_s is linked in or not)

A.

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Ian Stakenvicius]

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

On 31/08/12 10:56 AM, Alexis Ballier wrote:
> Michał Górny <mgorny@gentoo.org> wrote:
>> 
>> I believe that the more important direction here is to make 
>> development *easier*, not harder. Adding the same DEPENDs over
>> and over again to every single package is at least frustrating.
>> Similarly frustrating would be if those 'reduced systems' had to
>> rebuild gcc every time they wanted to compile something... oh
>> wait, they would have to bootstrap it every time.
>> 
> 
> you would achieve it better by adding pkgconfig to DEPEND in 
> eutils.eclass than putting it in @system since in the latter case
> it would also be a RDEPEND of everything basically
> 

And realistically that's where the DEPEND should be anyways, IMO --
appended by the eclass where the function is that uses it.  If this
means prune_libtool_files() gets separated out of eutils and put in
its own eclass (so that all the eutils inheritors don't suddenly need
virtual/pkgconfig unnecessarily), then so be it.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBA0rMACgkQ2ugaI38ACPB8dgD8CsXPJvPDjI3111dXT/z+gGUM
q8wTmMYqR2zVJasZMJQA/25de5bSofnwk4fXlCwPEFJ3Tu9rtCFRAx+q95oGFkad
=GWHe
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Jeff Horelick]

On 31 August 2012 11:05, Ian Stakenvicius <axs@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 31/08/12 10:56 AM, Alexis Ballier wrote:
>> Michał Górny <mgorny@gentoo.org> wrote:
>>>
>>> I believe that the more important direction here is to make
>>> development *easier*, not harder. Adding the same DEPENDs over
>>> and over again to every single package is at least frustrating.
>>> Similarly frustrating would be if those 'reduced systems' had to
>>> rebuild gcc every time they wanted to compile something... oh
>>> wait, they would have to bootstrap it every time.
>>>
>>
>> you would achieve it better by adding pkgconfig to DEPEND in
>> eutils.eclass than putting it in @system since in the latter case
>> it would also be a RDEPEND of everything basically
>>
>
> And realistically that's where the DEPEND should be anyways, IMO --
> appended by the eclass where the function is that uses it.  If this
> means prune_libtool_files() gets separated out of eutils and put in
> its own eclass (so that all the eutils inheritors don't suddenly need
> virtual/pkgconfig unnecessarily), then so be it.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iF4EAREIAAYFAlBA0rMACgkQ2ugaI38ACPB8dgD8CsXPJvPDjI3111dXT/z+gGUM
> q8wTmMYqR2zVJasZMJQA/25de5bSofnwk4fXlCwPEFJ3Tu9rtCFRAx+q95oGFkad
> =GWHe
> -----END PGP SIGNATURE-----
>

Also, I think that before many of these large changes happen, pkgconf
should become the default choice for the virtual. I'm sure embedded or
server users don't need/want Glib on their systems.

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

On Fri, 31 Aug 2012 11:05:23 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 31/08/12 10:56 AM, Alexis Ballier wrote:
> > Michał Górny <mgorny@gentoo.org> wrote:
> >> 
> >> I believe that the more important direction here is to make 
> >> development *easier*, not harder. Adding the same DEPENDs over
> >> and over again to every single package is at least frustrating.
> >> Similarly frustrating would be if those 'reduced systems' had to
> >> rebuild gcc every time they wanted to compile something... oh
> >> wait, they would have to bootstrap it every time.
> >> 
> > 
> > you would achieve it better by adding pkgconfig to DEPEND in 
> > eutils.eclass than putting it in @system since in the latter case
> > it would also be a RDEPEND of everything basically
> > 
> 
> And realistically that's where the DEPEND should be anyways, IMO --
> appended by the eclass where the function is that uses it.  If this
> means prune_libtool_files() gets separated out of eutils and put in
> its own eclass (so that all the eutils inheritors don't suddenly need
> virtual/pkgconfig unnecessarily), then so be it.

I wasn't referring to the function at the moment but at the overall
fact that practically any C/C++ package depending on any non-standard
library practically should depend on pkg-config. A library not
providing pkg-config file is simply broken.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

On Fri, 31 Aug 2012 07:48:23 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Fri, Aug 31, 2012 at 6:42 AM, Michał Górny <mgorny@gentoo.org>
> wrote:
> >
> > So please introduce virtual/compiler, virtual/linker,
> > virtual/posix-system, virtual/sratatata and add them to DEPEND of
> > every single ebuild.
> 
> Every ebuild doesn't need all of those - that is the whole point.  As
> Duncan already pointed out, reducing @system is a goal, but it doesn't
> mean that we need to get there overnight.  However, we'll never get
> there if we keep going backwards.

Reducing @system may be a goal but it should be a *reasonable* goal.
Not reducing because we can reduce but because it is bloated with
unneeded software.

We shouldn't even try to go below POSIX system requirements; we
shouldn't remove standard Linux stuff (from Linux profiles, at least)
either. And I believe toolchain belongs to @system as well; or at least
the C99 compiler.

And for a reasonable Gentoo toolchain, pkg-config is a must-have. At
least since we deprecated and are seriously fighting libtool.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 253 bytes --]

On 31-08-2012 18:08:12 +0200, Michał Górny wrote:
> And for a reasonable Gentoo toolchain, pkg-config is a must-have. At
> least since we deprecated and are seriously fighting libtool.

what?


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Ian Stakenvicius]

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

On 31/08/12 12:12 PM, Fabian Groffen wrote:
> On 31-08-2012 18:08:12 +0200, Michał Górny wrote:
>> And for a reasonable Gentoo toolchain, pkg-config is a must-have.
>> At least since we deprecated and are seriously fighting libtool.
> 
> what?

deprecated libtool = deprecated the installation of libtool's .la
files unless absolutely necessary



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBA5YEACgkQ2ugaI38ACPBdKwD/VBUh3YujIN6gTAQD1NkWGij0
NHQbKrTeqTZV5i7S7IQBAJwCvgNuJgFRioAUMJrFfwQvNO7xEbt+hFXCtLM1zWtf
=ognq
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

On Fri, 31 Aug 2012 18:12:58 +0200
Fabian Groffen <grobian@gentoo.org> wrote:

> On 31-08-2012 18:08:12 +0200, Michał Górny wrote:
> > And for a reasonable Gentoo toolchain, pkg-config is a must-have. At
> > least since we deprecated and are seriously fighting libtool.
> 
> what?

Libtool archives, I meant.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

[gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Duncan]

Michał Górny posted on Fri, 31 Aug 2012 18:08:12 +0200 as excerpted:

> Reducing @system may be a goal but it should be a *reasonable* goal. Not
> reducing because we can reduce but because it is bloated with unneeded
> software.
> 
> We shouldn't even try to go below POSIX system requirements; we
> shouldn't remove standard Linux stuff (from Linux profiles, at least)
> either. And I believe toolchain belongs to @system as well; or at least
> the C99 compiler.
> 
> And for a reasonable Gentoo toolchain, pkg-config is a must-have. At
> least since we deprecated and are seriously fighting libtool.

I think I see the problem.  Unsurprisingly it's a terminology definition 
mismatch problem, as so many are. =:^\

The reduce @system idea considers it a simple set of packages that are 
treated specially, and that exists to some degree for legacy reasons 
(back when gentoo was first being created, it was just easier to do it 
that way).  The (obviously long-term) goal would be to eliminate @system 
with its currently special treatment entirely, including POSIX 
components.  That may not be possible, but reducing it substantially 
should be.

But we're not talking actually removing packages from a default gentoo 
install, just increasing the number of packages that are directly 
specified depends and removing them from the @system _set_, until there's 
very little if anything left to it.

Thus, not adding it to @system in no way means it's not considered 
mandatory for a normal install, it just means the ultimate goal is to 
have all the deps specified and nothing left in @system, and while 
progress isn't fast by a long shot, the first thing is to ensure we're 
not regressing!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Mike Gilbert]

On Fri, Aug 31, 2012 at 2:16 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Thus, not adding it to @system in no way means it's not considered
> mandatory for a normal install, it just means the ultimate goal is to
> have all the deps specified and nothing left in @system, and while
> progress isn't fast by a long shot, the first thing is to ensure we're
> not regressing!
>

If the ultimate goal is to eliminate @system entirely (which it
probably isn't), we will need to revisit the way stage building works.
If understand correctly, a stage3 contains @system and its
dependencies.

The smallest you can really make @system under that circumstance would
be a working toolchain and the utilities necessary to build any other
needed packages. I think that is the goal that most people have been
shooting for lately.

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

On Fri, 31 Aug 2012 14:56:06 -0400
Mike Gilbert <floppym@gentoo.org> wrote:

> On Fri, Aug 31, 2012 at 2:16 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> > Thus, not adding it to @system in no way means it's not considered
> > mandatory for a normal install, it just means the ultimate goal is
> > to have all the deps specified and nothing left in @system, and
> > while progress isn't fast by a long shot, the first thing is to
> > ensure we're not regressing!
> >
> 
> If the ultimate goal is to eliminate @system entirely (which it
> probably isn't), we will need to revisit the way stage building works.
> If understand correctly, a stage3 contains @system and its
> dependencies.
> 
> The smallest you can really make @system under that circumstance would
> be a working toolchain and the utilities necessary to build any other
> needed packages. I think that is the goal that most people have been
> shooting for lately.

But you are aware that this will practically mean that there could be
no stand-alone ebuild repository because fulfilling the ebuild
dependencies wouldn't be anymore possible without providing all
of the standard system components, including those specified as
required by the PMS?

That in turn will make PMS utility requirements (bash, GNU find
etcetera) completely useless because the ebuilds will have to request
them explicitly anyway. But hey, you're aware that ebuilds use some of
those tools in global scope, before DEPEND is fulfilled? Also, I don't
think we have any kind of 'build'-time dependencies for binary
packages...
-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Alexis Ballier]

On Fri, 31 Aug 2012 18:03:33 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Fri, 31 Aug 2012 11:05:23 -0400
> Ian Stakenvicius <axs@gentoo.org> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> > 
> > On 31/08/12 10:56 AM, Alexis Ballier wrote:
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > >> 
> > >> I believe that the more important direction here is to make 
> > >> development *easier*, not harder. Adding the same DEPENDs over
> > >> and over again to every single package is at least frustrating.
> > >> Similarly frustrating would be if those 'reduced systems' had to
> > >> rebuild gcc every time they wanted to compile something... oh
> > >> wait, they would have to bootstrap it every time.
> > >> 
> > > 
> > > you would achieve it better by adding pkgconfig to DEPEND in 
> > > eutils.eclass than putting it in @system since in the latter case
> > > it would also be a RDEPEND of everything basically
> > > 
> > 
> > And realistically that's where the DEPEND should be anyways, IMO --
> > appended by the eclass where the function is that uses it.  If this
> > means prune_libtool_files() gets separated out of eutils and put in
> > its own eclass (so that all the eutils inheritors don't suddenly
> > need virtual/pkgconfig unnecessarily), then so be it.
> 
> I wasn't referring to the function at the moment but at the overall
> fact that practically any C/C++ package depending on any non-standard
> library practically should depend on pkg-config. A library not
> providing pkg-config file is simply broken.
> 

Hu? You know, some people think pkgconfig is a poorman's workaround for
a different problem. You don't need .pc files for dynamic linking
because:
1) there is a standard include search path
2) there is a standard library path
3) elf shared objects support dependencies

You might need pkgconfig for static linking because static archives do
not support 3). Isn't it the thing that should be improved instead ?

Alike you claim a library not providing a .pc is broken, I can claim
that a library relying on it is broken because it is violating 1)
and/or 2) which are well established unix behavior.

A.

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Rich Freeman]

On Fri, Aug 31, 2012 at 2:56 PM, Mike Gilbert <floppym@gentoo.org> wrote:
> On Fri, Aug 31, 2012 at 2:16 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>> Thus, not adding it to @system in no way means it's not considered
>> mandatory for a normal install, it just means the ultimate goal is to
>> have all the deps specified and nothing left in @system, and while
>> progress isn't fast by a long shot, the first thing is to ensure we're
>> not regressing!
>>
>
> If the ultimate goal is to eliminate @system entirely (which it
> probably isn't), we will need to revisit the way stage building works.
> If understand correctly, a stage3 contains @system and its
> dependencies.

The goal would be to eliminate @system entirely.

The solution to stage3 would be to have a set like @system of default
starting packages.  It might even be a defined set that users could
make use of (emerge @default), but ebuilds could not assume that they
are present.

To build them you just start with a working Gentoo system and emerge them.

>
> The smallest you can really make @system under that circumstance would
> be a working toolchain and the utilities necessary to build any other
> needed packages. I think that is the goal that most people have been
> shooting for lately.

Nobody is suggesting that a system containing no packages whatsoever
should be bootable, let alone usable to bootstrap everything else.
There would be some minimal set of packages needed to bootstrap the
rest.  However, ebuilds would need to explicitly declare their need
for them rather than assuming they are present.  Virtuals could be
used to simplify this.

In fact, there is a simple way to transition to such a system.  Start
by defining a virtual that contains everything that is in @system
(setting aside the issue that this is profile-dependent), and adding
that as a DEPEND and RDEPEND to every ebuild.  Then start paring it
down per-ebuild.

The goal is not to have working Gentoo systems that contain nothing on
their hard drives, but rather to eliminate the arbitrary collection of
packages that must be present everywhere, because some software that
might or might not even be installed could need them.

Rich

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2976 bytes --]

On Fri, 31 Aug 2012 16:01:01 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Fri, Aug 31, 2012 at 2:56 PM, Mike Gilbert <floppym@gentoo.org>
> wrote:
> > On Fri, Aug 31, 2012 at 2:16 PM, Duncan <1i5t5.duncan@cox.net>
> > wrote:
> >> Thus, not adding it to @system in no way means it's not considered
> >> mandatory for a normal install, it just means the ultimate goal is
> >> to have all the deps specified and nothing left in @system, and
> >> while progress isn't fast by a long shot, the first thing is to
> >> ensure we're not regressing!
> >>
> >
> > If the ultimate goal is to eliminate @system entirely (which it
> > probably isn't), we will need to revisit the way stage building
> > works. If understand correctly, a stage3 contains @system and its
> > dependencies.
> 
> The goal would be to eliminate @system entirely.
> 
> The solution to stage3 would be to have a set like @system of default
> starting packages.  It might even be a defined set that users could
> make use of (emerge @default), but ebuilds could not assume that they
> are present.
> 
> To build them you just start with a working Gentoo system and emerge
> them.
> 
> >
> > The smallest you can really make @system under that circumstance
> > would be a working toolchain and the utilities necessary to build
> > any other needed packages. I think that is the goal that most
> > people have been shooting for lately.
> 
> Nobody is suggesting that a system containing no packages whatsoever
> should be bootable, let alone usable to bootstrap everything else.
> There would be some minimal set of packages needed to bootstrap the
> rest.  However, ebuilds would need to explicitly declare their need
> for them rather than assuming they are present.  Virtuals could be
> used to simplify this.
> 
> In fact, there is a simple way to transition to such a system.  Start
> by defining a virtual that contains everything that is in @system
> (setting aside the issue that this is profile-dependent), and adding
> that as a DEPEND and RDEPEND to every ebuild.  Then start paring it
> down per-ebuild.
> 
> The goal is not to have working Gentoo systems that contain nothing on
> their hard drives, but rather to eliminate the arbitrary collection of
> packages that must be present everywhere, because some software that
> might or might not even be installed could need them.

That arbitrary collection of packages is called a system. I don't think
the goal for Gentoo should be to abandon standards like POSIX in favor
of 'design system yourself but don't come crying to us if you forget
some vital component which will make your system unbootable'.

Such a goals may be good for distributions like Exherbo which aim to
make everything perfect. I believe that Gentoo aims more around 'good
enough but at least realistic', instead of running for some kind of
utopia which simply does not work.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2657 bytes --]

On Fri, 31 Aug 2012 15:31:43 -0400
Alexis Ballier <aballier@gentoo.org> wrote:

> On Fri, 31 Aug 2012 18:03:33 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Fri, 31 Aug 2012 11:05:23 -0400
> > Ian Stakenvicius <axs@gentoo.org> wrote:
> > 
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA256
> > > 
> > > On 31/08/12 10:56 AM, Alexis Ballier wrote:
> > > > Michał Górny <mgorny@gentoo.org> wrote:
> > > >> 
> > > >> I believe that the more important direction here is to make 
> > > >> development *easier*, not harder. Adding the same DEPENDs over
> > > >> and over again to every single package is at least frustrating.
> > > >> Similarly frustrating would be if those 'reduced systems' had
> > > >> to rebuild gcc every time they wanted to compile something...
> > > >> oh wait, they would have to bootstrap it every time.
> > > >> 
> > > > 
> > > > you would achieve it better by adding pkgconfig to DEPEND in 
> > > > eutils.eclass than putting it in @system since in the latter
> > > > case it would also be a RDEPEND of everything basically
> > > > 
> > > 
> > > And realistically that's where the DEPEND should be anyways, IMO
> > > -- appended by the eclass where the function is that uses it.  If
> > > this means prune_libtool_files() gets separated out of eutils and
> > > put in its own eclass (so that all the eutils inheritors don't
> > > suddenly need virtual/pkgconfig unnecessarily), then so be it.
> > 
> > I wasn't referring to the function at the moment but at the overall
> > fact that practically any C/C++ package depending on any
> > non-standard library practically should depend on pkg-config. A
> > library not providing pkg-config file is simply broken.
> > 
> 
> Hu? You know, some people think pkgconfig is a poorman's workaround
> for a different problem. You don't need .pc files for dynamic linking
> because:
> 1) there is a standard include search path
> 2) there is a standard library path
> 3) elf shared objects support dependencies
> 
> You might need pkgconfig for static linking because static archives do
> not support 3). Isn't it the thing that should be improved instead ?
> 
> Alike you claim a library not providing a .pc is broken, I can claim
> that a library relying on it is broken because it is violating 1)
> and/or 2) which are well established unix behavior.

I'm not sure if you're aware of it but Gentoo doesn't aim at supporting
solely Linux and no other system.

Also, please tell me how to handle multiple slots sanely without
pkg-config in a package like Boost, for example.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Alexis Ballier]

On Fri, 31 Aug 2012 22:53:35 +0200
Michał Górny <mgorny@gentoo.org> wrote:

[...]
> I'm not sure if you're aware of it but Gentoo doesn't aim at
> supporting solely Linux and no other system.

elf != linux

> 
> Also, please tell me how to handle multiple slots sanely without
> pkg-config in a package like Boost, for example.
> 

You should know since you are proposing a boost-utils.eclass :)

Anyway, my point was just to go from 'not providing a .pc is broken' to
'.pc are useful and needed in some cases but not all'

A.

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

On Fri, 31 Aug 2012 17:49:34 -0400
Alexis Ballier <aballier@gentoo.org> wrote:

> On Fri, 31 Aug 2012 22:53:35 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> [...]
> > I'm not sure if you're aware of it but Gentoo doesn't aim at
> > supporting solely Linux and no other system.
> 
> elf != linux

Gentoo != elf only.

> > Also, please tell me how to handle multiple slots sanely without
> > pkg-config in a package like Boost, for example.
> 
> You should know since you are proposing a boost-utils.eclass :)

Eh, the world would be so much better if boost provided pkg-config
files.

For example, boost.m4 (provided by boost-m4) uses some wall-dumb
stubborn heuristics which always grabs newest boost and doesn't provide
any sane way to provide it with an older one...

> Anyway, my point was just to go from 'not providing a .pc is broken'
> to '.pc are useful and needed in some cases but not all'

But these some cases where there are needed result in the necessity
of installing them, and making the build systems aware of them. I don't
see much point in adding a 'backwards compatibility' to it as well.

Ah, while we're at it. If a library has macros referring
to the functions of another library (or just types) in its public API,
it needs a pkg-config file. ELF dependencies are not enough,
and the gold linker will refuse to work because of a missing explicit
dependency.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Gregory M. Turner]

On 8/31/2012 4:48 AM, Rich Freeman wrote:
> On Fri, Aug 31, 2012 at 6:42 AM, Michał Górny <mgorny@gentoo.org> wrote:
>>
>> So please introduce virtual/compiler, virtual/linker,
>> virtual/posix-system, virtual/sratatata and add them to DEPEND of every
>> single ebuild.
>
> Every ebuild doesn't need all of those - that is the whole point.  As
> Duncan already pointed out, reducing @system is a goal, but it doesn't
> mean that we need to get there overnight.  However, we'll never get
> there if we keep going backwards.

My 2c on this:

I'm reluctant to make "sweeping statements" like this, for any number of 
reasons, but -- well, I'm gonna.

IMO, getting there by slow evolution is not the right way.  At some 
point, @system becomes so primitive that bootstrapping must come to 
depend on more than @system, or we have to add add more "phases" to the 
bootstrap process, or split @system up into smaller sets or something.

The point is, we can't gradually reach a goal that's incompatible with 
the fundamental premise.  It's all well and good to say "let's not put 
more stuff into @system because we want it to shrink," but, as it 
stands, there's a de-facto policy that @system includes everything 
needed to have a reasonably functional Gentoo, including all of the 
compilers, development tools and interpreters portage, gcc, and your rc 
system of choice rely on.  Until that fundamentally changes, IMO what 
belongs in @system is whatever best suits its current purpose.

For the record, I'm not saying we need to put pkgconfig in - I'm totally 
agnostic about that, as I am about whether it should be brought in as a 
dependency.

I just mean, probably the best way to fix the fat-@system problem is to 
create some kind of vision for a more-modular "Gentoo of the Future" 
first, and create a roadmap for getting there, second.

Its possible, perhaps even likely, that if we try to go the incremental 
route towards @system reduction, we will find, along the way, creative 
solutions to the various issues that have kept it fat-ish so far.  But 
that's likely to lead to a fairly ad-hoc patchwork of hacks, which imo 
would most likely be inferior to what could be achieved with some kind 
of destination in mind (even if that destination is subject to major 
revision as Gentoo progress toward it).

-gmt

[gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Duncan]

Gregory M. Turner posted on Fri, 31 Aug 2012 16:13:20 -0700 as excerpted:

> For the record, I'm not saying we need to put pkgconfig in - I'm totally
> agnostic about that, as I am about whether it should be brought in as a
> dependency.

[Just replying here as it's handy.]

I don't believe the following bit has been explicitly stated yet.  I'm 
not sure if it's sufficiently implicit that it doesn't need stated for 
not, but in case it helps:

The effect of adding pkgconfig to @system is just this:  Currently, we 
have an explicit list of all packages that need it (barring missing 
dependency bugs, of course).  If it gets added to @system, that list 
immediately gets decimated, and while its historical value can always be 
dug out of the VCS (as long as the git upgrade or whatever doesn't lose 
that information, anyway), it's no longer being updated and will quickly 
go stale, so when the time comes and we DO decide to finally seriously 
tackle @system removal, that's one more dependency that we have to go to 
(excuse the shouting) ALL THE WORK OF RECREATING THE DATA WE CURRENTLY 
HAVE, ALL OVER AGAIN.

We have that data for pkgconfig now, and currently, it must be maintained 
in at least a semi-reasonable state.  If we ever DO get serious about 
@system removal, we'll definitely need that data.  So let's not go 
voluntarily dumping it down the toilet, which is what adding pkgconfig to 
@system would amount to, only to decide we actually need that data after 
all, but by then it'll be gone, so we'll have to recreate it from 
scratch.  That's what all this is about, not adding yet another package 
to the list of packages we don't HAVE proper dependency data for, data 
that we'll have to create from scratch if we ever do decide to move on 
the @system removal thing, when for this package at least, we already HAD 
it, and will have deliberately thrown it away by adding the package to 
@system.


If it was as simple as just adding it to the list, and we weren't 
throwing away a quite valuable bunch of already accumulated dependency 
data as a result, sure, no problem, go right ahead.  Unfortunately...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Alexis Ballier]

On Sat, 1 Sep 2012 01:05:39 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Fri, 31 Aug 2012 17:49:34 -0400
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Fri, 31 Aug 2012 22:53:35 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > [...]
> > > I'm not sure if you're aware of it but Gentoo doesn't aim at
> > > supporting solely Linux and no other system.
> > 
> > elf != linux
> 
> Gentoo != elf only.

Prefix? Come on, some usecases do not make pkgconfig so vital for every
gentoo install that it should be in @system.

> > > Also, please tell me how to handle multiple slots sanely without
> > > pkg-config in a package like Boost, for example.
> > 
> > You should know since you are proposing a boost-utils.eclass :)
> 
> Eh, the world would be so much better if boost provided pkg-config
> files.
> 
> For example, boost.m4 (provided by boost-m4) uses some wall-dumb
> stubborn heuristics which always grabs newest boost and doesn't
> provide any sane way to provide it with an older one...

Yes, pkgconfig can be useful, sometimes...

> > Anyway, my point was just to go from 'not providing a .pc is broken'
> > to '.pc are useful and needed in some cases but not all'
> 
> But these some cases where there are needed result in the necessity
> of installing them, and making the build systems aware of them. I
> don't see much point in adding a 'backwards compatibility' to it as
> well.

If the build system needs pkgconfig then the ebuild should depend on
it, whats wrong with that ? I dont need pkgconfig to run the package
after its built. For the same reason people have been working to
_remove_ flex, m4, bison, autoconf, automake from @system, pkgconfig
does not belong there either...

> Ah, while we're at it. If a library has macros referring
> to the functions of another library (or just types) in its public API,
> it needs a pkg-config file. ELF dependencies are not enough,
> and the gold linker will refuse to work because of a missing explicit
> dependency.

Eh, straight to the point where pkgconfig is not the solution to
everything: a binary not using said macros but trusting pkgconfig will
get overlinked. Documentation stating that when using these
macros/functions one should link to the other lib would make things
even better.

A.

[gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

On Fri, 31 Aug 2012 22:51:08 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> That arbitrary collection of packages is called a system. I don't think
> the goal for Gentoo should be to abandon standards like POSIX in favor
> of 'design system yourself but don't come crying to us if you forget
> some vital component which will make your system unbootable'.

"Gentoo" is actually an old Navaho word meaning "some assembly required,
batteries not included".  You thought it was a penguin?

> Such a goals may be good for distributions like Exherbo which aim to
> make everything perfect. I believe that Gentoo aims more around 'good
> enough but at least realistic', instead of running for some kind of
> utopia which simply does not work.

I don't understand your stance here, because to me 'good enough but
realistic' means ignoring standards when they're stupid, embracing them when
they're not, and forging your own where they don't yet exist.  Perfection, by
definition, requires an existing standard to hold yourself up against.


-- 
gcc-porting
toolchain, wxwidgets          we were never more here, expanse getting broader
@ gentoo.org                          but bigger boats been done by less water

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

On Fri, 31 Aug 2012 20:14:43 -0400
Alexis Ballier <aballier@gentoo.org> wrote:

> > Ah, while we're at it. If a library has macros referring
> > to the functions of another library (or just types) in its public
> > API, it needs a pkg-config file. ELF dependencies are not enough,
> > and the gold linker will refuse to work because of a missing
> > explicit dependency.
> 
> Eh, straight to the point where pkgconfig is not the solution to
> everything: a binary not using said macros but trusting pkgconfig will
> get overlinked. Documentation stating that when using these
> macros/functions one should link to the other lib would make things
> even better.

The macros/types can change over time. Maintaining all indirect
dependencies is not friendly nor useful.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Alexis Ballier]

On Sat, 1 Sep 2012 09:40:47 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Fri, 31 Aug 2012 20:14:43 -0400
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > > Ah, while we're at it. If a library has macros referring
> > > to the functions of another library (or just types) in its public
> > > API, it needs a pkg-config file. ELF dependencies are not enough,
> > > and the gold linker will refuse to work because of a missing
> > > explicit dependency.
> > 
> > Eh, straight to the point where pkgconfig is not the solution to
> > everything: a binary not using said macros but trusting pkgconfig
> > will get overlinked. Documentation stating that when using these
> > macros/functions one should link to the other lib would make things
> > even better.
> 
> The macros/types can change over time. Maintaining all indirect
> dependencies is not friendly nor useful.
> 

So in this hypothetic case where your lib changes its ABI and API, it
is not friendly and seen useless by consumers, I think I agree :)

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Rich Freeman]

On Fri, Aug 31, 2012 at 11:50 PM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> On Fri, 31 Aug 2012 22:51:08 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
>> Such a goals may be good for distributions like Exherbo which aim to
>> make everything perfect. I believe that Gentoo aims more around 'good
>> enough but at least realistic', instead of running for some kind of
>> utopia which simply does not work.
>
> I don't understand your stance here, because to me 'good enough but
> realistic' means ignoring standards when they're stupid, embracing them when
> they're not, and forging your own where they don't yet exist.  Perfection, by
> definition, requires an existing standard to hold yourself up against.

In any case, I wasn't suggesting that a typical user would run without
POSIX.  I just think that we'd be better off if our dependencies were
fully specified which will aid those doing unusual things with Gentoo.

Keep in mind that unusual unix-like implementations are all around us.
 I doubt a Tivo even has a shell installed, and a typical Android
phone has a very non-traditional set of tools available.

I think the default Gentoo install should be pretty similar to what it
is today.  However, more flexibility to deviate isn't a bad thing.

That said, having fully specified dependencies without giving
headaches to maintainers is also a good goal.  I think that absent
better tools @system is always going to have to be a compromise.

Rich