[gentoo-dev] [EBUILD] unknown description

2014-10-16 Thread sp4ze

Hi,

I try to make a deadbeef ebuild

I have two unknown description ( faad and zip )

- - faad : unknown description
- - zip : unknown description

DEADBEEF README:
...
faad2: for AAC plugin
libzip: for vfs_zip plugin
...

Here is a brief description of my ebuild :

IUSE=... faad zip ...
RDEPEND=...
faad? ( media-libs/faad2 )
zip? ( dev-libs/libzip )

I looked the other ebuild using faad ( mpd, mplayer... ) but I see no 
difference with mine.


For libzip I think I did not use the correct flag.

--
Sp4ze



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
 dilfri...@gentoo.org 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] [EBUILD] unknown description

2014-10-16 Thread Kent Fredric
On 17 October 2014 08:54, sp4ze sp...@sp4ze.net wrote:

 I looked the other ebuild using faad ( mpd, mplayer... ) but I see no
 difference with mine.



grep faad /usr/portage/media-video/mplayer/metadata.xml

 flag name=faadUse external faad library for AAC decoding/flag

grep faad /usr/portage/media-sound/mpd/metadata.xml

   flag name=faadUse external faad library for AAC decoding/flag

-- 
Kent

*KENTNL* - https://metacpan.org/author/KENTNL


Re: [gentoo-dev] [EBUILD] unknown description

2014-10-16 Thread sp4ze

I missed the gentoo manual page metadata. shame on me

Thx Kent


--
Sp4ze



Re: [gentoo-dev] [EBUILD] unknown description

2014-10-16 Thread Diego Elio Pettenò
And if faad is *required* for aac it should not use faad as USE flag, but
aac.

Because in the case of mplayer it's selecting faad *over libavcodec*. In
other cases faad is depended upon with aac because it is required to play
back aac files.

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

On 16 October 2014 20:57, Kent Fredric kentfred...@gmail.com wrote:


 On 17 October 2014 08:54, sp4ze sp...@sp4ze.net wrote:

 I looked the other ebuild using faad ( mpd, mplayer... ) but I see no
 difference with mine.



 grep faad /usr/portage/media-video/mplayer/metadata.xml

  flag name=faadUse external faad library for AAC decoding/flag

 grep faad /usr/portage/media-sound/mpd/metadata.xml

flag name=faadUse external faad library for AAC decoding/flag

 --
 Kent

 *KENTNL* - https://metacpan.org/author/KENTNL