it seems it only controls using bundled pccts or system one; as we have an ebuild for it i don't think leaving the option to use the bundled one is useful and we should not allow using bundled apps/libs.
Pccts is abandonware which conflict with antlr. See bug 90844. cdrdao is the only package which needs it and cdrdao's version is more recent than what we have in tree (it has a few warning fixes). Do we really want to pull in a dependency that blocks a rather popular package?
(In reply to comment #1) > Pccts is abandonware which conflict with antlr. See bug 90844. cdrdao is the > only package which needs it and cdrdao's version is more recent than what we > have in tree (it has a few warning fixes). if these fixes are really a must have then they should be in the pccts ebuild too > Do we really want to pull in a > dependency that blocks a rather popular package? wouldn't it be possible to use antlr instead? (assuming cdrdao isn't abandonware too)
(In reply to comment #2) > wouldn't it be possible to use antlr instead? (assuming cdrdao isn't > abandonware too) i'm afraid it is.. my 1 cent
As seems that cdrdao is the only package that can depend on dev-util/pccts and its pccts bundled version is better, why not mask dev-util/pccts for removal and rely on bundled pccts for cdrdao?
That would probably be a good idea given that pccts is not well maintained either.
What was done in tree: - Removed the USE flag and dependency from cdrdao Removing media-optical@
dev-util/cccc depends on this package.
kensington: backported most of -r1 to -r0 in cccc's ebuild, please review and explore the route of using antlr instead of pccts?
(In reply to comment #8) > kensington: backported most of -r1 to -r0 in cccc's ebuild, please review > and explore the route of using antlr instead of pccts? Thanks. Porting to antlr will not be trivial, so pccts will have to stay bundled for that package too.
dropped
