Arch Linux

sounds nice, +1 as long as gtk2 (or whatever it requires) will be optional dependency for cdrdao package (with a hint in post_install).

-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.

I just came along this thread in the forums:
http://bbs.archlinux.org/viewtopic.php?id=34585

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.

And another thread:
http://bbs.archlinux.org/viewtopic.php?id=26889

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.

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

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.

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.

Filed a feature request to upstream. ;-)
https://sourceforge.net/tracker/index.php?func=detail&aid=2435117&group_id=2171&atid=352171

Sorry, just another thought. What's about providing two cdrdao packages, cdrdao for CLI only and cdrdaox for CLI+GUI?

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.

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.

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.

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?

Could it be an optdepend? See avidemux.

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.

-1 for gtk dependency.

Why not set gtk as optdepends instead of depends?

Hmm, *can* we use optdepends for this case? If we build gcdmaster, does it break anything else?

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.

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

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.

+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.

@Dan
free to look into this and split the package

Attached is a theoretical split package.... should work, but it doesn't build for me. Fails out during compile due to a g++ error.