Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#9797 - [cdrdao] Please install with gcdmaster

Attached to Project: Arch Linux
Opened by Heiko Baums (cyberpatrol) - Sunday, 09 March 2008, 20:23 GMT
Last edited by Dan Griffiths (Ghost1227) - Saturday, 27 February 2010, 00:42 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Aaron Griffin (phrakture)
Andrea Scarpino (BaSh)
Architecture All
Severity Low
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


cdrdao includes a nice GUI which is called GCDMaster. In my experience it's one of the best if not the best GUI tools for copying CDs. I'm getting the best results with this tool.

Unfortunately it's not installed on Arch Linux. So it would be nice if cdrdao would be installed with GCDMaster.

I think to get it compiled, the ./configure line in the PKGBUILD has to be changed to this:
./configure --prefix=/usr --with-lame --with-ogg-support --with-mp3-support --with-xdao

And it would be nice, if the file $startdir/src/$pkgname-$pkgver/xdao/gcdmaster.desktop would also be installed, if it's not done automatically.
This task depends upon

Closed by  Dan Griffiths (Ghost1227)
Saturday, 27 February 2010, 00:42 GMT
Reason for closing:  Implemented
Additional comments about closing:  Finally made the split package... stupid RAM issues
Comment by Roman Kyrylych (Romashka) - Sunday, 09 March 2008, 20:54 GMT
sounds nice, +1 as long as gtk2 (or whatever it requires) will be optional dependency for cdrdao package (with a hint in post_install).
Comment by Greg (dolby) - Monday, 10 March 2008, 10:20 GMT
-1 one from me for including this in a standard cdrdao installation.
IMHO for such tools, focus should always be given to their commandline operation.
If the submitter and anyone else wants to use gcdmaster, he can build it himself & optionally upload it to AUR as cdrdao-gcdmaster or something.
Comment by Heiko Baums (cyberpatrol) - Tuesday, 16 December 2008, 18:35 GMT
I just came along this thread in the forums:

See especially dtw's posting:
"As far as pkg containing server+client: it's generally Arch policy not to make two packages from one src file. So if the src contains code for client and server binaries then the pkg will."

I think it's generally the same here, even if it's not a client server solution. But gcdmaster belongs to cdrdao and is included in the same source file. So why building two different packages, if cdrdao and gcdmaster belong together.

The appropriate GUI library could of course be an optional dependency, as Roman suggested.
Comment by Heiko Baums (cyberpatrol) - Tuesday, 16 December 2008, 18:41 GMT
And another thread:

See here iphitus' posting:
"pacman -S netkit-telnet

you get the server too, we dont split it. but it won't run by default, so hopefully that isnt a problem for you."

Well, I know, that these threads are about telnet, but I guess it's quite similar. Not everyone needs a telnet server, but the client.
Comment by Aaron Griffin (phrakture) - Tuesday, 16 December 2008, 18:48 GMT
This one's a little iffy and different, because it can be configured out, and it adds GUI deps.

I dunno how I feel about it... I think we SHOULD provide this if it's in the original source, but adding lots more deps seems kinda gross... and adding this as an optdepend seems a little odd

/me shrugs hard
Comment by Heiko Baums (cyberpatrol) - Tuesday, 16 December 2008, 20:39 GMT
This is what the INSTALL file in the source package says about the dependencies:
"GCDMaster is written in C++ and therefore requires the Gnome/Gtk C++
bindings to build (libsigc++, gtkmm and libgnomeuimm)."

I'm not quite sure, if these are "only" build time or also runtime dependencies.
A runtime dependency seems to be GTK 2.
Comment by Heiko Baums (cyberpatrol) - Tuesday, 16 December 2008, 20:48 GMT
Forgot to say, that I wouldn't have a problem, if the GCDMaster dependencies would be optional dependencies. I also wouldn't like to have them as dependencies for cdrdao, if I had a CLI only system. And most users, who are using X have these dependencies installed anyway. So it shouldn't be such a big problem, if these dependencies were optional.

I don't know if GCDMaster can be built seperately without cdrdao. Then it could probably be built as a seperate package. But in the INSTALL file only the .configure option --with(out)-xdao is mentioned. So I guess it can only be built together with cdrdao.
Comment by Heiko Baums (cyberpatrol) - Tuesday, 16 December 2008, 21:10 GMT Comment by Heiko Baums (cyberpatrol) - Tuesday, 16 December 2008, 21:34 GMT
Sorry, just another thought. What's about providing two cdrdao packages, cdrdao for CLI only and cdrdaox for CLI+GUI?
Comment by Dan McGee (toofishes) - Wednesday, 17 December 2008, 05:56 GMT
Not sure why this is marked for closure when no real consensus was reached. If this truely is the best GUI available for copying CDs, it should probably be made available in some form rather than suggest people learn to use the CLI. If it is not easily splittable, then I'm not sure what the answer is.
Comment by Greg (dolby) - Sunday, 28 December 2008, 23:29 GMT
2 notes:
Although this feature request has been opened for 10 months, noone bothered to upload a cdrdao package on AUR (even before the FR was opened).
For me that would mean that noone really uses the GUI. & quite frankly if users considered it important, you gotta admit that it would already be up there.
And another thing. Dont count on upstream. The least of the projects concerns, which i have serious doubts its actually alive, is splitting gcdmaster from cdrdao.
Just my 2 cents.
Comment by Heiko Baums (cyberpatrol) - Monday, 29 December 2008, 00:37 GMT
Grigorios, you are the only one here, who's strictly against gcdmaster and who strictly argues not to put it into the repos. I'm asking myself why. Does this gui hurt you? Or is your harddisk so small, that these few additional KBs are too big? Or are there other possibly personal reasons? Everyone else here is at least not against the gui or even likes the idea, having this gui in the cdrdao package.

Is it possible, that there's just no cdrdao package in AUR or another request here in the flyspray, because gcdmaster is just not so well known? But this wouldn't mean, that this gui is bad. I also got to know gcdmaster only by accident. But when I found it, I tried it and I liked it. Or is it possible, that not so many gcdmaster users have switched to Archlinux, yet? Maybe I'm the first. I, btw., haven't put a package to AUR, because gcdmaster belongs to cdrdao, which is already in the repos. And due to the Archlinux guidelines, as I understand them, gcdmaster rather belongs to this cdrdao package than to a new AUR package.

I don't think, too, that splitting gcdmaster from cdrdao has the top priority for upstream. But this is just a feature request, which also doesn't hurt anyone. And it's just a suggestion and one possible way to fix this issue.

But I think, this is not the right place for such an unobjective discussion.

To stop this type of discussion and to come back to the facts, I think you and me gave our opinions. So let us decide the devs. I guess they'll come to a reasonable decision.
Comment by Greg (dolby) - Thursday, 12 February 2009, 16:34 GMT
The good news is upstream marked CVS as 1.2.3 RC1 so its not completely dead.
On some other news, the ChangeLog says "Preferences now stored in GConf, exports schema file". Does this mean that the GUI will depend on GNOME?
Comment by Alessandro Doro (adoroo) - Friday, 13 February 2009, 14:03 GMT
Could it be an optdepend? See avidemux.
Comment by Jan de Groot (JGC) - Sunday, 16 August 2009, 17:32 GMT
I updated to 1.3.2RC2 for now. Including gcdmaster means including dependencies on gtkmm, gnomemm, etc. I haven't implemented this for now because I'm rebuilding old packages to have their manpages corrected and .FILELIST excluded. Implementing this cleanly would mean building a split package.
Comment by Pawel (kraftman) - Saturday, 12 September 2009, 13:43 GMT
-1 for gtk dependency.
Comment by Heiko Baums (cyberpatrol) - Saturday, 12 September 2009, 15:44 GMT
Why not set gtk as optdepends instead of depends?
Comment by Aaron Griffin (phrakture) - Tuesday, 22 September 2009, 18:52 GMT
Hmm, *can* we use optdepends for this case? If we build gcdmaster, does it break anything else?
Comment by Heiko Baums (cyberpatrol) - Tuesday, 22 September 2009, 20:45 GMT
I think for compiling libsigc++, gtkmm and libgnomeuimm are needed, but for the users it should be sufficient to put them to optdepends. I don't see why it should break anything. gcdmaster would be installed but just won't run if these libraries aren't installed.

An alternative would be a splitted package with only gcdmaster, but I think cdrdao needs to be compiled anyway to get gcdmaster, because there's only a configure option --without-xdao but no configure option --without-cdrdao or --xdao-only.
Comment by Aaron Griffin (phrakture) - Tuesday, 22 September 2009, 21:17 GMT
Hmm a split package will work as well, but I think optdepends are best here assuming the rest of the package works as it used to
Comment by Jan de Groot (JGC) - Wednesday, 23 September 2009, 07:01 GMT
Now that we have split package support, I think that abusing optdepends for this is not the way to go. Please split the package and add the correct dependencies to the gcdmaster package.
Comment by Dan Griffiths (Ghost1227) - Monday, 15 February 2010, 22:28 GMT
+1 for making this a split package, building the package would be easy and would allow the user the choice of including the GUI component or not.
Comment by Andrea Scarpino (BaSh) - Monday, 15 February 2010, 22:35 GMT
free to look into this and split the package
Comment by Dan Griffiths (Ghost1227) - Tuesday, 16 February 2010, 00:06 GMT
Attached is a theoretical split package.... should work, but it doesn't build for me. Fails out during compile due to a g++ error.