Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 198779 - app-cdr/cdrtools has automagic sys-apps/acl dependency
Summary: app-cdr/cdrtools has automagic sys-apps/acl dependency
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Gentoo Optical Media project
URL:
Whiteboard:
Keywords:
: 245840 245845 249925 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-11 09:16 UTC by euclid80
Modified: 2009-02-01 13:45 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Adds "with-acl" and "without-acl" options to the configure script. (cdrtools-2.01.01_alpha34-extraflags.patch,902 bytes, patch)
2007-11-11 09:18 UTC, euclid80
Details | Diff
Adds 'acl' USE flag to cdrtools ebuild (cdrtools-ebuild.patch,1010 bytes, patch)
2007-11-11 09:20 UTC, euclid80
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description euclid80 2007-11-11 09:16:22 UTC
The build scripts for cdrtools will detect the presence of the acl libraries and use them automatically.  However, this leads to dependencies that Portage doesn't know about, so I suggest that the use of acl be controlled by a USE flag.

Reproducible: Always

Steps to Reproduce:
1.install sys-apps/acl
2.install cdrtools
3.remove sys-apps/acl

Actual Results:  
cdrtools has missing dynamic links

Expected Results:  
a warning when sys-apps/acl is unmerged

I'll upload a patch for this.  It may need some cleaning up, as I am not an ebuild expert.
Comment 1 euclid80 2007-11-11 09:18:39 UTC
Created attachment 135718 [details, diff]
Adds "with-acl" and "without-acl" options to the configure script.
Comment 2 euclid80 2007-11-11 09:20:47 UTC
Created attachment 135719 [details, diff]
Adds 'acl' USE flag to cdrtools ebuild
Comment 3 Lars Weiler (RETIRED) gentoo-dev 2007-11-11 12:04:45 UTC
cdrtools-2.01.01a36 has some changes according to ACL (see ftp://ftp.berlios.de/pub/cdrecord/alpha/AN-2.01.01a36).  Probably your patch is not needed any more on that version.

Furthermore you check for 'acllib.h' in your patch (actually, cdrtools check for that file as well), but this one does not get installed by sys-apps/acl.  So your patch will always fail.

On the other hand I try to keep cdrtools as unpatched as needed, as it seems to be a fragile framework for patches.  Especially when you need support from upstream and use a heavily patched version.  So I'm more in favour of adding sys-apps/acl as a hard dependency rather than creating a patch and test for the existance of those header-files.
Comment 4 Steve Dibb (RETIRED) gentoo-dev 2008-01-05 06:15:38 UTC
(In reply to comment #3)
> cdrtools-2.01.01a36 has some changes according to ACL (see
> ftp://ftp.berlios.de/pub/cdrecord/alpha/AN-2.01.01a36).  Probably your patch is
> not needed any more on that version.
> 
> Furthermore you check for 'acllib.h' in your patch (actually, cdrtools check
> for that file as well), but this one does not get installed by sys-apps/acl. 
> So your patch will always fail.
> 
> On the other hand I try to keep cdrtools as unpatched as needed, as it seems to
> be a fragile framework for patches.  Especially when you need support from
> upstream and use a heavily patched version.  So I'm more in favour of adding
> sys-apps/acl as a hard dependency rather than creating a patch and test for the
> existance of those header-files.
> 

Agreed, added to cdrtools-2.01.01_alpha36-r1.ebuild

Comment 5 Rémi Cardona (RETIRED) gentoo-dev 2008-01-06 14:51:03 UTC
Is there any chance the hard ACL dep could be discussed with (and the patch approved by) upstream devs?

Thanks
Comment 6 Jeroen Roovers (RETIRED) gentoo-dev 2008-11-07 06:52:01 UTC
*** Bug 245840 has been marked as a duplicate of this bug. ***
Comment 7 Jeroen Roovers (RETIRED) gentoo-dev 2008-11-07 06:53:07 UTC
*** Bug 245845 has been marked as a duplicate of this bug. ***
Comment 8 Jeroen Roovers (RETIRED) gentoo-dev 2008-11-07 06:53:44 UTC
People don't like this hard dep. :)
Comment 9 Peter Alfredsen (RETIRED) gentoo-dev 2008-11-07 17:33:01 UTC
If people have a problem with the hard dep, they may bug upstream.
Comment 10 Philippe Chaintreuil 2008-11-10 14:31:58 UTC
> If people have a problem with the hard dep, they may bug upstream.

Wait, can you explain to me why this is a hard dep?

Why isn't ACL just used if ACL is installed, and not used if it's not installed?

I don't see anything in this bug that suggests that not having ACL installed breaks cdrtools.

If the acl use flag is on, then ACL will be used, if it's off, then it presumable isn't installed and won't be built against.  There's no need to patch cdrtools' dist; this is just a one line change to the .ebuild.


The original report is a revdep-rebuild problem:  Of course linking to a library and then deleting that shared library will screw up an executable!  That's like complaining that gnome stopped working when I deleted X!

If you respected the use flag, you'd get rid of ACL by "-acl" and emerge -uDNv1 world and everything would end up kosher -- the same would be true in the other direction (turning on "acl").
Comment 11 kavol 2008-11-10 15:11:26 UTC
(In reply to comment #10)
> If the acl use flag is on, then ACL will be used, if it's off, then it
> presumable isn't installed and won't be built against.  There's no need to
> patch cdrtools' dist; this is just a one line change to the .ebuild.
> 
> 
> The original report is a revdep-rebuild problem:  Of course linking to a
> library and then deleting that shared library will screw up an executable! 
> That's like complaining that gnome stopped working when I deleted X!

no, this is not the exact problem ... the problem is that if you have acl library installed for some reason, but USE="-acl", then cdrtools builds with dependency on acl anyway, and if you remove acl library then cdrtools breaks, which would not be catched by emerge -N

... if I get it right ;-)

however, a hard dependency on acl is not the way IMHO; we have the revdep-rebuild utility, and there will be "preserved libraries" emerge functionality (if I understand correctly how does it work - I tried to use newer portage on one system because of the bleeding edge KDE, and it complained about libs not unistalled because still in use by other packages ...)

btw, as for bugging the upstream, it used to be a nice custom that the one who closes the bug this way reports the upstream bug and put a link to it into the closed bug ...
Comment 12 Philippe Chaintreuil 2008-11-10 15:59:00 UTC
> the problem is that if you have acl library installed for some reason,
> but USE="-acl", then cdrtools builds with dependency on acl anyway,
> and if you remove acl library then cdrtools breaks, which would not
> be catched by emerge -N

This sounds like a pretty edge case: someone who installed acl, but has -acl.

If we're really worried about that, the .ebuild could test for acl being installed and output a warning for this edge case; ie:

------------------------------------------------------------------------
if use '-acl' ; then
   if has_version sys-apps/acl ; then
      ewarn "-acl detected, but acl is installed.  This is bad mojo!"
      ewarn "You're on your own if you continue!"
   fi
fi
------------------------------------------------------------------------

Wouldn't that be better than the hard-dep?
Comment 13 Peter Alfredsen (RETIRED) gentoo-dev 2008-11-10 17:28:44 UTC
We will not accept automagic dependencies, so this is the resolution.

Upstream is pretty fast to claim that any change to his build system voids any "responsibility" he has for it, going so far as to suggest that people who use GNU Make aren't really right in their heads. So be it. We try as far as possible to not make changes to the build system. If any of our users have a problem with this they may bug upstream with a patch and when he accepts it, we apply it. Not before.

Anyone who wishes to file a bug with upstream may do so:
Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>

I promise I'll be quick to incorporate it if it's accepted.
Comment 14 Philippe Chaintreuil 2008-11-10 17:42:45 UTC
What is the upstream bug?  He auto-detect if you have ACL or not, doesn't he?
Comment 15 Stuart W. Finlayson 2008-11-10 23:18:20 UTC
If I understand this correctly, it's not a question of auto-detecting, but a question of making acl support optional in the cdrtools build configuration.  Currently it is not optional, if you have acl installed cdrtools is compiled with support for it (whether you want it in there or not).  Therefore, making it optional in the ebuild is not possible.

That being said, I'm not familiar enough with autoconf to create a working patch to submit upstream.  And the one submitted here doesn't work correctly according to Lars...
Comment 16 Jeroen Roovers (RETIRED) gentoo-dev 2008-11-11 07:35:06 UTC
(In reply to comment #15)
> If I understand this correctly, it's not a question of auto-detecting, but a
> question of making acl support optional in the cdrtools build configuration. 
> Currently it is not optional, if you have acl installed cdrtools is compiled
> with support for it (whether you want it in there or not).  Therefore, making
> it optional in the ebuild is not possible.

Sure, but then you'd have automagic. Now the question is whether we want automagic or a strict dependency, regardless of USE=acl, which would wreak havoc on your system otherwise anyway, because lots of other packages pull in acl support when they find sys-apps/acl anyway. I don't see this as an upstream choice. :)
Comment 17 kavol 2008-11-12 12:25:47 UTC
ok, I spent quite some time trying to force cdrtools not to link against libacl despite acl being installed, and I had no success :-(

I tried the attached patch (after fixing it), I tried to sed in unpack to remove any acl.h, USE_ACL, ACL_LIB and similar references, and still ...

jarmilka cdrtools # equery f cdrtools | grep bin | grep -v debug | xargs ldd | grep acl
ldd: /usr/bin: není obyčejným souborem
        libacl.so.1 => /lib/libacl.so.1 (0x0000003496e00000)
        libacl.so.1 => /lib/libacl.so.1 (0x0000003496e00000)

:-(

there has to be some voodoo in it or what ...
Comment 18 Thomas 2008-11-25 00:58:27 UTC
(In reply to comment #9)
> If people have a problem with the hard dep, they may bug upstream.

There is no upstream bug.  The idea of autoconf is to use whatever it finds on the system.  For autoconf automagic is intended by design.  So there is a clash of paradigms between autoconf and portage, which is not specific for cdrtools or acl and which cannot be resolved.

As mentioned above, the originally mentioned "problem" is not related to cdrtools at all.  emerge will happily remove any library, be it used by other packages or not.  The only difference is, that emerge will re-install the removed library if it knows about the dependencies.  However, there is a perfectly well suited tool for this case called revdep-rebuild.

The voices above say: a useful and pragmatic way is to drop the hard dependency.  Even if Peter were formally right, insisting on a hard dependency breaks a higher good: gentoo's commitment to choice.

And in case Peter keeps thinking that forcing people to install useless libraries is a good solution for a non existing problem, there is a well suited work around as well: putting sys-apps/acl into /etc/portage/package.provided makes portage consider this dependency as already solved.
Comment 19 Rémi Cardona (RETIRED) gentoo-dev 2008-11-25 07:23:32 UTC
(In reply to comment #18)
> There is no upstream bug.

Then please open one. :)

>  The idea of autoconf is to use whatever it finds on
> the system.  For autoconf automagic is intended by design.  So there is a clash
> of paradigms between autoconf and portage, which is not specific for cdrtools
> or acl and which cannot be resolved.

That is just plain wrong. Autoconf has no "default paradigm". It only does what the developers want it to do. If they want full automagical detection, autoconf can do that. If they want to add configure switches for every single feature, autoconf can do that as well.

> The voices above say: a useful and pragmatic way is to drop the hard
> dependency.  Even if Peter were formally right, insisting on a hard dependency
> breaks a higher good: gentoo's commitment to choice.

There's no such commitment. There is, however, a maintainer's choice. Peter made a decision and given all the elements, I happen to think he made the right one.

> And in case Peter keeps thinking that forcing people to install useless
> libraries is a good solution for a non existing problem, there is a well suited
> work around as well: putting sys-apps/acl into /etc/portage/package.provided

Again, that's _wrong_. Peter already told everyone what the real solution is: getting it fixed upstream.

That's where energy should be better spent. :)

Thanks
Comment 20 kavol 2008-11-25 08:23:46 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > There is no upstream bug.
> 
> Then please open one. :)
...
> Peter already told everyone what the real solution is:
> getting it fixed upstream.
> 
> That's where energy should be better spent. :)

now the question is: is somebody going to try to get it fixed upstream, PLEASE?

- don't look at me, I know nearly nothing about the autoconf stuff, and I am just an ordinary user who does not want to have the acl libraries installed, not the one who can tell them about the packaging troubles

(In reply to comment #18)
> And in case Peter keeps thinking that forcing people to install useless
> libraries is a good solution for a non existing problem, there is a well suited
> work around as well: putting sys-apps/acl into /etc/portage/package.provided
> makes portage consider this dependency as already solved.

thanks for the tip!
Comment 21 Thomas 2008-11-25 16:05:57 UTC
Short summary:

Upstream cdrtools is not broken, it does what its author intends it to do.
> comment #13:
> We will not accept automagic dependencies

Why not?  We are not interested in some ideology about purity of build systems, we are interested in a lean and working system.  Why not be pragmatic here?

(In reply to comment #19)
> (In reply to comment #18)
> > There is no upstream bug.
> 
> Then please open one. :)

There is no reason to.  Just in case someone did not get this yet: the upstream package works as expected by its author (Jörg): it detects acl if it is present and compiles fine if it doesn't.  So what you expect him to do now is to change this behaviour, which is perfectly suitable for anyone, even in the gentoo universe, except for those who are unable to use revdep-rebuild.

> > The idea of autoconf is to use whatever it finds on
> > the system.  For autoconf automagic is intended by design.  So there is a clash
> > of paradigms between autoconf and portage, which is not specific for cdrtools
> > or acl and which cannot be resolved.
> 
> That is just plain wrong. Autoconf has no "default paradigm".

Is it?  You are right, there is the possibility of switching features on or off.  There is no necessity to do this, however.  The way Peter understands portage differs there from, but as described e. g. in Bug 245840, other package maintainers don't bother (read: waste their time) trying to convince upstream projects to adhere to some gentoo maintainers' understanding of how autoconf should be used.

> It only does what
> the developers want it to do. If they want full automagical detection, autoconf
> can do that. If they want to add configure switches for every single feature,
> autoconf can do that as well.

In our case, Jörg decided to use automagic.  Where is the bug?

> > ... insisting on a hard dependency
> > breaks a higher good: gentoo's commitment to choice.
> 
> There's no such commitment.

Read this: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=1 (just the first paragraph ;-).  This is why i am here: because gentoo allows me to install packages by my requirements and not by what some maintainer thinks my or most people's requirements are.  I know that this is not Peters intention, but it is the result of his decision.

> There is, however, a maintainer's choice. Peter
> made a decision and given all the elements, I happen to think he made the right
> one.

There seem to be a number of users (among them me ;-) who disagree.  I try to give some rational reasons (among my rants against being patronised ;-) why this choice does not meet users' requirements and should be reconsidered.

> > And in case Peter keeps thinking that forcing people to install useless
> > libraries is a good solution for a non existing problem, there is a well suited
> > work around as well: putting sys-apps/acl into /etc/portage/package.provided
> 
> Again, that's _wrong_. Peter already told everyone what the real solution is:
> getting it fixed upstream.

Yes, according to what he and you consider being right or wrong.  Upstream (i. e. Jörg) might deviate from Peter's opinion of "right" usage of autoconf and might (and will) refuse to fix what is not broken.

> That's where energy should be better spent. :)

Go ahead and ask Jörg.  If he bothers to answer at all, his answer will not be to your liking. ;->

> comment #20:
> now the question is: is somebody going to try to get it fixed upstream,
> PLEASE?

And, please, post the answer here, if there is one. ;->
Comment 22 Rémi Cardona (RETIRED) gentoo-dev 2008-11-25 17:38:50 UTC
I'll just reply to select bits and pieces.

(In reply to comment #21)
> Why not?  We are not interested in some ideology about purity of build systems,

*We* are! It's the only way *we* can guarantee a stable system to reduce the number of bugs. If you can't understand that, it's not even worth going further.

We're miles away from purity, just take a look at ebuilds, there are hundreds of workarounds for lots of things.

> There is no reason to.  Just in case someone did not get this yet: the upstream
> package works as expected by its author (Jörg): it detects acl if it is
> present and compiles fine if it doesn't.  So what you expect him to do now is
> to change this behaviour, which is perfectly suitable for anyone, even in the
> gentoo universe, except for those who are unable to use revdep-rebuild.

1) (speaking with my gnome hat on) Most gnome packages use autodetection by default but allow configure switches. There's nothing incompatible about the 2 approaches.

2) revdep-rebuild is a tool that should never be used, in the sense that we don't consider running revdep-rebuild a *normal* operation. It's meant to be exceptional.

> In our case, Jörg decided to use automagic.  Where is the bug?

Automagic is fine when we can override it. See point #1 above.

> Read this: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=1
> (just the first paragraph ;-).  This is why i am here: because gentoo allows me
> to install packages by my requirements and not by what some maintainer thinks
> my or most people's requirements are.  I know that this is not Peters
> intention, but it is the result of his decision.

Peter's decision is the _direct_ result of upstream's decision. Since it is also Gentoo policy to follow upstream as closely as possible...

> Yes, according to what he and you consider being right or wrong.  Upstream (i.
> e. Jörg) might deviate from Peter's opinion of "right" usage of autoconf and
> might (and will) refuse to fix what is not broken.

Now, to be fair, I wanted to see how long it would take for me to hack up cdrtools to have both autodetection and configure switches.

But now I see that the *REAL* issue is that cdrtools does *NOT* use autotools, but use a hand-crafted system of makefiles which is orders of magnitude worse than autotools.

I now *completely* understand why Peter refuses to waste time hacking on what could only be characterized as a monumental waste of time.

I was seriously hoping I could patch things to find a win-win situtation for everyone. Now I'm just hoping cdrtools dies a painful death.
Comment 23 Philippe Chaintreuil 2008-11-25 20:27:15 UTC
> 2) revdep-rebuild is a tool that should never be used, in the sense that
> we don't consider running revdep-rebuild a *normal* operation. It's meant
> to be exceptional.

Which this situation is.  The original bug spells out steps which are equivilant to:

1.)  emerge gnome
2.)  emerge -C gtk+

...and expecting gnome to continue working.  This is where revdep-rebuild is supposed to be used.



> It's the only way *we* can guarantee a stable system to reduce
> the number of bugs.

This doesn't seem to be working, see bugs #245840 & #245845.  You're getting more bugs because people see this as a Gentoo issue.  Users don't think they should be required to installed ACL when said program does not require ACL.



As for an upstream bug, I don't understand why Peter or Rémi don't file one.  They are in the best position to articulate why they want this.  I would say that everyone else looking at this bug thinks it's a Gentoo issue, not a cdrtools issue.  See Thomas's argument for this position.



If upstream refuses to add these flags, what is going to become of this?

Comment 24 Peter Alfredsen (RETIRED) gentoo-dev 2008-11-25 21:04:11 UTC
> If upstream refuses to add these flags, what is going to become of this?

Nothing.

Please stop talking on this bug and start talking to upstream. When upstream insists on blocking himself into his own little world, using only his own little tools and dismissing everyone else as morons, he can damn well maintain his own little package. If there's something wrong with the packaging, please do file a bug and I will fix it. Fast even. But the build system is broken and we know it. Please file a bug upstream. We once cared, but until it's fixed, all you'll get is a gallic shrug. C'est la vie.
Comment 25 Thomas 2008-11-26 10:05:04 UTC
(In reply to comment #24)
> Please stop talking on this bug and start talking to upstream.

We certainly won't, because this discussion is about if there is an upstream bug at all.  I tried to explain why there isn't, and i didn't see any explanation yet, why an upstream developer's decision to rely on auto-detection without giving the choice to override it should be a bug.

Furthermore, others have pointed out, that many other packages use this policy as well and their gentoo maintainers accept upstream developers' decision without adding strict dependencies to everything what might be detected.

(In reply to comment #24)
> Now I'm just hoping cdrtools dies a painful death.

If this is your opinion, you may well leave this project (and discussion) to those who are interested in a solution and who are able to value other developers' work.

Speaking of this: development of cdrtools started more than 20 years ago on Solaris (ever heard of?), when linux didn't yet exist, as didn't the autoconf tools.  So a bit more modesty when judging Jörg's development environment might be appropriate.  Please keep in mind that Jörg is the one who created this software and maintains it to date.  If he rejects your advice which tools to use, you will probably have to live with it.
Comment 26 Samuli Suominen (RETIRED) gentoo-dev 2008-11-26 10:33:21 UTC
(In reply to comment #25)
> (In reply to comment #24)
> > Please stop talking on this bug and start talking to upstream.
> 
> We certainly won't, because this discussion is about if there is an upstream
> bug at all.  I tried to explain why there isn't, and i didn't see any
> explanation yet, why an upstream developer's decision to rely on auto-detection
> without giving the choice to override it should be a bug.

It's a bug because if you have ACL installed on your system, but you are prebuilding a binary package for an system which doesn't there will be a
simple "Unable to find shared library." -error which everyone should understand.

Automagics are automatically bugs, please see http://www.gentoo.org/proj/en/qa/automagic.xml if they can't be configured off by a switch. It's pain
for source distributions, but also a pain for binary distribution maintainers.

So it is really simple, please think re-think about it from binary distributions maintainers point of view and source distributions users point of view. Thanks!
Comment 27 Thomas 2008-11-26 13:37:00 UTC
(In reply to comment #26)
> It's a bug because if you have ACL installed on your system, but you are
> prebuilding a binary package for an system which doesn't there will be a
> simple "Unable to find shared library." -error which everyone should
> understand.

From Wikipedia:

> A software bug (or just “bug”) is an error, flaw, mistake, failure, fault
> or “undocumented feature” in a computer program that prevents it from
> behaving as intended

Now the question arises: intended by whom?  Since Jörg created the build system, he is the only relevant person to decide, if this behaviour is intended or not.  If it is, there is no upstream bug.

> Automagics are automatically bugs,

Now, if the combination of portage and cdrtools does not work as intended by the integrators (Peter et al.), there is a bug in the integration.  Still not upstream, but here.  It may be impossible (what seems to be the case) to fix this bug without changing the upstream package.  This does not change the fact, that there is no bug in the upstream package.  The upstream package is just not suitable for integration with portage as is, but nobody assured it to be.

> It's pain
> for source distributions, but also a pain for binary distribution maintainers.

Of course this behaviour intended by Jörg may be undesirable for others.  They can go and ask (!) Jörg to change (note: not to "fix"!) this, if they are unable to do it themselves.  This, however, is not a bug report and should not be communicated as such.

Apart from the above formal point,there is a pragmatic issue: (figures just guessed)

- how many people would like to use cdrtools without acl dependency (95%)
- how many of them have the skills to circumvent the dependency (20%)
- how many of the creators of binary packages have to manage the dependency according to their needs (100%)

Based upon my guessing, Peter would do his users a favour by dropping the acl dependency.  This would cause a bug that hardly anyone notices to remain in the integration, but this bug obviously ubiquitous.  You simply cannot build a binary distribution independent from acl on a system having libacl.
Comment 28 kavol 2008-11-26 13:54:08 UTC
(In reply to comment #27)
> - how many people would like to use cdrtools without acl dependency (95%)

one correction, IMHO:

- how many people just do not care and do not notice (95%)
- how many of those who care would like to use the whole system without unnecessary dependencies (95%)

and yes, as I am in those 95% of the 5%, I mostly agree with your point
Comment 29 Rémi Cardona (RETIRED) gentoo-dev 2008-11-26 14:13:27 UTC
The problem is that cdrtools deployement is not compatible with portage. Period.

The solution is either to fix portage (not going to happen for one stray package) or to fix cdrtools (not going to happen either because upstream already said no).

If you're so unhappy with this situation, then don't use cdrtools. There are plenty of other burning apps.

I'll be now closing this bug because this discussion has been going on for much too long and is now completely pointless.

Angst and flames should be sent at upstream, regardless of their age. Being 10 years older than the Linux kernel does not make a project better.

Thanks
Comment 30 Philippe Chaintreuil 2008-11-26 15:05:05 UTC
> The solution is either to fix portage (not going to happen for one
> stray package) or to fix cdrtools (not going to happen either
> because upstream already said no).

    This isn't true.   The people who wanted upstream to fix this issue, wouldn't go ask is beyond me.

    Instead I asked (even though I *still* think it's a Gentoo issue).

    Jörg says in his latest code you can call make as follows to disable ACL usage in cdrtools:

------------------------------------------
make COPTX=-DNO_ACL "LIB_ACL_TEST= "
------------------------------------------

    He notes and warns that the ACL interface takes place in libfind (distributed with cdrtools), and that other programs he develops also use libfind (for example app-arch/star).  If libfind is installed as a shared library and both these packages use it, this could be an collision issue.  (But that's another bug, not this one.)  (It also implies that this same issue ACL  exists with app-arch/star, but I don't use it, so I don't care.)
    He points out that static linking can be used by appending "LINKMODE=static" to that make command.

   Full text (helpful stuff is at the end):
   https://lists.berlios.de/pipermail/cdrecord-support/2008-November/002569.html

> If you're so unhappy with this situation, then don't use cdrtools. There
> are plenty of other burning apps.

    Although I will note that before you made that statement I didn't even realize virtual/cdrtools existed, I just thought there was only app-cdr/cdrtools.

    So on a productive note, I think I'm in kavol's boat.  I could care less about cdrtools.  I use K3B & nautilus-cd-burner to burn CDs, which use virtual/cdrtools.  app-cdr/cdrtools was installed by portage automatically when I installed one of those (possibly before virtual/cdrtools existed), so I'm going to switch to cdrkit (assuming it works just fine) and drop app-cdr/cdrtools.  Now....

    Rémi, is there a way to make cdrkit the default/preferred provider for virtual/cdrtools and reduce Gentoo's dependence on app-cdr/cdrtools, which it's Gentoo shepherds hate?  Thomas, would this be acceptable to you, or do you actually have a love of/reason to cling to app-cdr/cdrtools?
Comment 31 Thomas 2008-11-26 16:11:06 UTC
(In reply to comment #30)
> Thomas, would this be acceptable to you, or do you
> actually have a love of/reason to cling to app-cdr/cdrtools?

Well, i use cdrtools for more than 15 years now (starting on OS/2 ;-), so this is not a purely rational issue for me. ;-)

However, there also seem to be rational reasons not to use cdrkit, look here: http://cdrecord.berlios.de/private/linux-dist.html

If Jörg's statements are correct, cdrkit is unmaintained.  (Does it support blue ray burning?)  At least, it seems inferior, bug- and feature-wise.

> If you're so unhappy with this situation
I am unhappy with the situation, but not because of cdrtools, but because of its gentoo maintainers, who are quite eager trying to shut down a useful discussion instead of facing it.
Comment 32 Samuli Suominen (RETIRED) gentoo-dev 2008-11-26 17:11:35 UTC
Speaking in behalf of media-optical, I think will now start moving to new-style virtual for called virtual/cdrtools as libburnia used as default provider, second provider is the cdrkit, and at last, final impl. cdrtools.

I'm going to discuss with libburnia upstream is it's ready for this.

This way we can deprecate cdrtools slowly from Gentoo.
Comment 33 Norman Jonas 2008-12-05 16:20:33 UTC
*** Bug 249925 has been marked as a duplicate of this bug. ***
Comment 34 Peter Alfredsen (RETIRED) gentoo-dev 2009-02-01 13:43:08 UTC
Reopen
Comment 35 Peter Alfredsen (RETIRED) gentoo-dev 2009-02-01 13:45:29 UTC
+*cdrtools-2.01.01_alpha57 (01 Feb 2009)
+
+  01 Feb 2009; Peter Alfredsen <loki_val@gentoo.org>
+  -cdrtools-2.01.01_alpha41.ebuild, -cdrtools-2.01.01_alpha42.ebuild,
+  -cdrtools-2.01.01_alpha50-r3.ebuild, -cdrtools-2.01.01_alpha52.ebuild,
+  +cdrtools-2.01.01_alpha57.ebuild:
+  Bump, fix bug 253229. Also fix bug 198779, acl automagic dependency.
+