Re: [gentoo-dev] new virtual: virtual/podofo-build

2014-10-16 Thread Zac Medico
On 10/15/2014 05:36 AM, Rich Freeman wrote:
> On Wed, Oct 15, 2014 at 7:42 AM, Andreas K. Huettel
>  wrote:
>>> In order to solve bug #503802 [1], I would like to add a
>>> virtual/podofo-build package to pull in app-text/podofo and
>>> dev-libs/boost. Then packages like app-text/calibre can put
>>> virtual/podofo-build in DEPEND and app-text/podofo in RDEPEND.
>>
>> This sounds a bit like a one-time solution for a problem that occurs more
>> frequently... It would be nice to have a more generic solution. :|
> 
> If A depends on B, and in order to build A you need C, but in order to
> run B you do not need C, does it make sense to specify C as a
> dependency of B, rather than as a dependency of A?
> 
> The risk I would see is whether that relationship holds 100% of the
> time.  What if somebody comes up with an alternative to boost that is
> not 100% compatible, but it works for calibre (but not other packages
> that DEPEND on podofo)?
> 
> I can see how this approach would work for something like
> split-headers.  However, when you get into things like build systems
> it seems like this could be problematic.  However, I haven't been
> thinking about this for 3 years...  :)

Here's where virtuals are more flexible than the BADEPEND suggested in
bug 392239. If we later find that virtual/podofo-build works for calibre
but not some other reverse-dependency of podofo, then we can always
create a different virtual to put in DEPEND of said reverse-dependency.
-- 
Thanks,
Zac



Re: [gentoo-dev] new virtual: virtual/podofo-build

2014-10-15 Thread Rich Freeman
On Wed, Oct 15, 2014 at 7:42 AM, Andreas K. Huettel
 wrote:
>> In order to solve bug #503802 [1], I would like to add a
>> virtual/podofo-build package to pull in app-text/podofo and
>> dev-libs/boost. Then packages like app-text/calibre can put
>> virtual/podofo-build in DEPEND and app-text/podofo in RDEPEND.
>
> This sounds a bit like a one-time solution for a problem that occurs more
> frequently... It would be nice to have a more generic solution. :|

If A depends on B, and in order to build A you need C, but in order to
run B you do not need C, does it make sense to specify C as a
dependency of B, rather than as a dependency of A?

The risk I would see is whether that relationship holds 100% of the
time.  What if somebody comes up with an alternative to boost that is
not 100% compatible, but it works for calibre (but not other packages
that DEPEND on podofo)?

I can see how this approach would work for something like
split-headers.  However, when you get into things like build systems
it seems like this could be problematic.  However, I haven't been
thinking about this for 3 years...  :)

--
Rich



Re: Re: [gentoo-dev] new virtual: virtual/podofo-build

2014-10-15 Thread Andreas K. Huettel
> On 10/15/2014 04:42 AM, Andreas K. Huettel wrote:
> >> In order to solve bug #503802 [1], I would like to add a
> >> virtual/podofo-build package to pull in app-text/podofo and
> >> dev-libs/boost. Then packages like app-text/calibre can put
> >> virtual/podofo-build in DEPEND and app-text/podofo in RDEPEND.
> > 
> > This sounds a bit like a one-time solution for a problem that occurs more
> > frequently... It would be nice to have a more generic solution. :|
> 
> I's only been in the pms-bugs queue for about 3 years now:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=392239

Right. My mind is full of holes.

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, council




Re: [gentoo-dev] new virtual: virtual/podofo-build

2014-10-15 Thread Zac Medico
On 10/15/2014 04:42 AM, Andreas K. Huettel wrote:
>> In order to solve bug #503802 [1], I would like to add a
>> virtual/podofo-build package to pull in app-text/podofo and
>> dev-libs/boost. Then packages like app-text/calibre can put
>> virtual/podofo-build in DEPEND and app-text/podofo in RDEPEND. 
> 
> This sounds a bit like a one-time solution for a problem that occurs more 
> frequently... It would be nice to have a more generic solution. :|


I's only been in the pms-bugs queue for about 3 years now:

https://bugs.gentoo.org/show_bug.cgi?id=392239

-- 
Thanks,
Zac



Re: [gentoo-dev] new virtual: virtual/podofo-build

2014-10-15 Thread Andreas K. Huettel
> In order to solve bug #503802 [1], I would like to add a
> virtual/podofo-build package to pull in app-text/podofo and
> dev-libs/boost. Then packages like app-text/calibre can put
> virtual/podofo-build in DEPEND and app-text/podofo in RDEPEND. 

This sounds a bit like a one-time solution for a problem that occurs more 
frequently... It would be nice to have a more generic solution. :|

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, council




Re: [gentoo-dev] new virtual: virtual/podofo-build

2014-10-14 Thread Zac Medico
On 10/14/2014 06:42 PM, Zac Medico wrote:
> On 10/14/2014 06:20 PM, Rich Freeman wrote:
>> So, if the podofo-build virtual listed boost in its RDEPENDs that
>> would be fine.  However, it would seem simpler to me to just list
>> boost in the calibre DEPENDs.
> 
> Yeah, boost in the calibre DEPENDs satisfies my `emerge --depclean
> --with-bdeps=n` requirement, so I guess KISS wins here.

With some investigation, I've realized that podofo has a USE flag which
allows the boost dependency to be disabled. So, it would be unfortunate
if calibre pulled in boost when it wasn't needed. Given this issue, the
virtual seems more appealing.
-- 
Thanks,
Zac



Re: [gentoo-dev] new virtual: virtual/podofo-build

2014-10-14 Thread Zac Medico
On 10/14/2014 06:20 PM, Rich Freeman wrote:
> So, if the podofo-build virtual listed boost in its RDEPENDs that
> would be fine.  However, it would seem simpler to me to just list
> boost in the calibre DEPENDs.

Yeah, boost in the calibre DEPENDs satisfies my `emerge --depclean
--with-bdeps=n` requirement, so I guess KISS wins here.
-- 
Thanks,
Zac



Re: [gentoo-dev] new virtual: virtual/podofo-build

2014-10-14 Thread Rich Freeman
On Tue, Oct 14, 2014 at 6:56 PM, Alex Xu  wrote:
> I feel like there should be a DEPEND specifier for "packages required to
> build against this package". For example, xproto is required to build
> against SDL (at least using pkg-config), but not to simply use it at
> runtime. This applies even if one does not directly use xproto headers.
>
> It would not be sufficient to specify that "DEPEND includes the DEPENDs
> and RDEPENDs of the dependencies", since then it would be impossible to
> specify build dependencies that only require the runtime of the
> dependee, like most build tools.

I thought that a package could only assume that the direct DEPENDs
were installed anyway.  Those DEPENDs could only assume that their
immediate RDEPENDs are installed when they're used to build something
else.

So, if the podofo-build virtual listed boost in its RDEPENDs that
would be fine.  However, it would seem simpler to me to just list
boost in the calibre DEPENDs.

I'm not really opposed to having a special reverse build DEPEND
variable of some kind, but does it really add that much value?

If I ever got around to building that portage sandbox extension that
blocked read access to anything that wasn't in DEPENDS, or RDEPENDs of
DEPENDs, and so on, or @system, then it would detect these kinds of
situations.

--
Rich



Re: [gentoo-dev] new virtual: virtual/podofo-build

2014-10-14 Thread Zac Medico
On 10/14/2014 03:56 PM, Alex Xu wrote:
> On 13/10/14 03:46 PM, Zac Medico wrote:
>> Hi,
>>
>> In order to solve bug #503802 [1], I would like to add a
>> virtual/podofo-build package to pull in app-text/podofo and
>> dev-libs/boost. Then packages like app-text/calibre can put
>> virtual/podofo-build in DEPEND and app-text/podofo in RDEPEND. The
>> advantage of this approach is that it makes it possible to use a command
>> like `emerge --depclean --with-bdeps=n` to remove the build-time only
>> boost package (and virtual/podofo-build), since boost is only needed for
>> build-time headers. There may be some other possible ways to specify the
>> dependency, but this approach is the most attractive one that I've seen.
>> In fact, this approach is basically identical to the "Virtual for C++
>> tr1 " example that's given in the dev-manual [2].
>>
>> Would anyone like to suggest improvements to this idea, alternatives, or
>> raise any objections?
>>
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=503802
>> [2] http://devmanual.gentoo.org/general-concepts/virtuals/
>>
> 
> I feel like there should be a DEPEND specifier for "packages required to
> build against this package". For example, xproto is required to build
> against SDL (at least using pkg-config), but not to simply use it at
> runtime. This applies even if one does not directly use xproto headers.
> 
> It would not be sufficient to specify that "DEPEND includes the DEPENDs
> and RDEPENDs of the dependencies", since then it would be impossible to
> specify build dependencies that only require the runtime of the
> dependee, like most build tools.

We can add that in a future EAPI:

https://bugs.gentoo.org/show_bug.cgi?id=392239

> It seems like a poor solution to have to create virtuals for every
> package that requires such an arrangement.

Well, it's not quite as convenient as having an EAPI extension that's
specifically designed for that purpose. However, using virtuals gives us
the desired result without having to wait for a new EAPI.
-- 
Thanks,
Zac



Re: [gentoo-dev] new virtual: virtual/podofo-build

2014-10-14 Thread Alex Xu
On 13/10/14 03:46 PM, Zac Medico wrote:
> Hi,
> 
> In order to solve bug #503802 [1], I would like to add a
> virtual/podofo-build package to pull in app-text/podofo and
> dev-libs/boost. Then packages like app-text/calibre can put
> virtual/podofo-build in DEPEND and app-text/podofo in RDEPEND. The
> advantage of this approach is that it makes it possible to use a command
> like `emerge --depclean --with-bdeps=n` to remove the build-time only
> boost package (and virtual/podofo-build), since boost is only needed for
> build-time headers. There may be some other possible ways to specify the
> dependency, but this approach is the most attractive one that I've seen.
> In fact, this approach is basically identical to the "Virtual for C++
> tr1 " example that's given in the dev-manual [2].
> 
> Would anyone like to suggest improvements to this idea, alternatives, or
> raise any objections?
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=503802
> [2] http://devmanual.gentoo.org/general-concepts/virtuals/
> 

I feel like there should be a DEPEND specifier for "packages required to
build against this package". For example, xproto is required to build
against SDL (at least using pkg-config), but not to simply use it at
runtime. This applies even if one does not directly use xproto headers.

It would not be sufficient to specify that "DEPEND includes the DEPENDs
and RDEPENDs of the dependencies", since then it would be impossible to
specify build dependencies that only require the runtime of the
dependee, like most build tools.

It seems like a poor solution to have to create virtuals for every
package that requires such an arrangement.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] new virtual: virtual/podofo-build

2014-10-13 Thread Zac Medico
Hi,

In order to solve bug #503802 [1], I would like to add a
virtual/podofo-build package to pull in app-text/podofo and
dev-libs/boost. Then packages like app-text/calibre can put
virtual/podofo-build in DEPEND and app-text/podofo in RDEPEND. The
advantage of this approach is that it makes it possible to use a command
like `emerge --depclean --with-bdeps=n` to remove the build-time only
boost package (and virtual/podofo-build), since boost is only needed for
build-time headers. There may be some other possible ways to specify the
dependency, but this approach is the most attractive one that I've seen.
In fact, this approach is basically identical to the "Virtual for C++
tr1 " example that's given in the dev-manual [2].

Would anyone like to suggest improvements to this idea, alternatives, or
raise any objections?

[1] https://bugs.gentoo.org/show_bug.cgi?id=503802
[2] http://devmanual.gentoo.org/general-concepts/virtuals/
-- 
Thanks,
Zac