If you install the transmission package it will bring gtk and a lot of other dependences that you may don't want, if you only want to install transmission-cli and/or transmission-daemon. I think that the transmission package should be splitted in more atomic packages to leave the possibility to the user to decide which part of it install.
Sounds reasonable. I have been wanting to look into this for a while. Ankur Sinha, do you want to take a stab at splitting it up?
For comparison, Debian splits it up into transmission-cli, -common and -gtk which would be a good method to follow.
(In reply to comment #1) > Sounds reasonable. I have been wanting to look into this for a while. Ankur > Sinha, do you want to take a stab at splitting it up? hey Rahul, how's this spec for a "stab"? http://ankursinha.fedorapeople.org/transmission/transmission.spec regards, Ankur
You need to add the appropriate obsoletes to ensure a smooth update path. Install the previous version. Build this locally and make sure rpm -Uvh works.
(In reply to comment #4) > You need to add the appropriate obsoletes to ensure a smooth update path. > Install the previous version. Build this locally and make sure rpm -Uvh >works. hi, done that, spec etc can be found here: http://ankursinha.fedorapeople.org/transmission/ regards, Ankur
- Change Obsoletes: transmission = 1.76-1 to Obsoletes: transmission <= 1.76-1 since one might have an older package installed. - You're duplicating a lot of files! Put them in a common (noarch?) subpackage.
Hello, I'm glad about this initiative -- I'm building my splitted transmission package myself but somehow didn't think of requesting that in Bugzilla yet so thank you for doing this. I took a look at your spec file and quite frankly I don't understand what you are trying to achieve. Seems like the result should be 4 rpms: transmission, transmission-common, trnasmission-cli and transmission-gtk, where transmission should contain everything (same as now), -cli only command line tools -gtk GUI and -common the files required for all the binaries... Now look at the %files sections: %files -f %{name}.lang %defattr(-, root, root, -) %doc AUTHORS COPYING NEWS README %{_bindir}/transmission* %{_datadir}/transmission %{_datadir}/pixmaps/* %{_datadir}/icons/hicolor/*/apps/transmission.* %{_datadir}/applications/*transmission.desktop %doc %{_mandir}/man1/transmission* %files common -f %{name}.lang %defattr(-, root, root, -) %doc AUTHORS COPYING NEWS README %{_bindir}/transmission-daemon %{_bindir}/transmission-remote %doc %{_mandir}/man1/transmission-* %files cli -f %{name}.lang %defattr(-, root, root, -) %{_bindir}/transmissioncli %doc %{_mandir}/man1/transmissioncli* %files gtk -f %{name}.lang %defattr(-, root, root, -) %{_bindir}/transmission %{_datadir}/transmission %{_datadir}/pixmaps/* %{_datadir}/icons/hicolor/*/apps/transmission.* %{_datadir}/applications/*transmission.desktop %doc %{_mandir}/man1/transmission.* As Jussi Lehtola already pointed out: the base package doesn't need to contain any files at -- it could just become a meta-package and require all the others, or it could just contain the GTK gui and depend on the cli and common packages and you can leave out the -gtk subpackage... Other problem here is that transmission-daemon requires the files from %{_datadir}/transmission (that's the web interface). I admit I also don't understand separating transmission-daemon and transmissioncli -- IIRC they have both the same dependencies and by not installing the transmissioncli one would save about 400 kB (which sounds funny, especially in Fedora). So if I may suggest I would split to two packages only: transmission-cli containing the daemon, remote, text client and web interface files. This package wouldn't drag in the GTK and X dependencies when installed. Then you can add the rest (GTK GUI with icons, etc.) to the base package that would depend on the -cli subpackage. This way the new transmission package would be identical to the one we have right now but it would be possible to install just the -cli subpackage without the dependencies. However: the daemon must have the %{_datadir}/transmission files installed. And I think the obsoletes are wrong. It should be Obsoletes: transmission < 1.80-0.3.b4
(In reply to comment #6) > - Change > Obsoletes: transmission = 1.76-1 > to > Obsoletes: transmission <= 1.76-1 > since one might have an older package installed. > > - You're duplicating a lot of files! Put them in a common (noarch?) >subpackage. (In reply to comment #7) > Hello, > I'm glad about this initiative -- I'm building my splitted transmission > package myself but somehow didn't think of requesting that in Bugzilla yet so > thank you for doing this. > > I took a look at your spec file and quite frankly I don't understand what you > are trying to achieve. Seems like the result should be 4 rpms: transmission, > transmission-common, trnasmission-cli and transmission-gtk, where transmission > should contain everything (same as now), -cli only command line tools -gtk GUI > and -common the files required for all the binaries... > hey, thank you for the detailed review > Now look at the %files sections: > > %files -f %{name}.lang > %defattr(-, root, root, -) > %doc AUTHORS COPYING NEWS README > %{_bindir}/transmission* > %{_datadir}/transmission > %{_datadir}/pixmaps/* > %{_datadir}/icons/hicolor/*/apps/transmission.* > %{_datadir}/applications/*transmission.desktop > %doc %{_mandir}/man1/transmission* > > %files common -f %{name}.lang > %defattr(-, root, root, -) > %doc AUTHORS COPYING NEWS README > %{_bindir}/transmission-daemon > %{_bindir}/transmission-remote > %doc %{_mandir}/man1/transmission-* > > %files cli -f %{name}.lang > %defattr(-, root, root, -) > %{_bindir}/transmissioncli > %doc %{_mandir}/man1/transmissioncli* > > %files gtk -f %{name}.lang > %defattr(-, root, root, -) > %{_bindir}/transmission > %{_datadir}/transmission > %{_datadir}/pixmaps/* > %{_datadir}/icons/hicolor/*/apps/transmission.* > %{_datadir}/applications/*transmission.desktop > %doc %{_mandir}/man1/transmission.* > > As Jussi Lehtola already pointed out: the base package doesn't need to contain > any files at -- it could just become a meta-package and require all the others, Why i havent removed the %files for the base package: Removing the %files section means no rpm package named "transmission" being created. Since folks are still going to be using "yum update transmission", I cannot allow that to happen. It would break the update path. (please correct me if I'm wrong here) > or it could just contain the GTK gui and depend on the cli and common packages > and you can leave out the -gtk subpackage... This seems like a better option > > Other problem here is that transmission-daemon requires the files from > %{_datadir}/transmission (that's the web interface). ah, I missed that. i'll correct that > > I admit I also don't understand separating transmission-daemon and > transmissioncli -- IIRC they have both the same dependencies and by not > installing the transmissioncli one would save about 400 kB (which sounds funny, > especially in Fedora). > > So if I may suggest I would split to two packages only: transmission-cli > containing the daemon, remote, text client and web interface files. This > package wouldn't drag in the GTK and X dependencies when installed. Then you > can add the rest (GTK GUI with icons, etc.) to the base package that would > depend on the -cli subpackage. This way the new transmission package would be > identical to the one we have right now but it would be possible to install just > the -cli subpackage without the dependencies. However: the daemon must have > the %{_datadir}/transmission files installed. > by this rationale, it makes most sense to leave the base package and create only a -cli package. I'll try this out in the mean time. > And I think the obsoletes are wrong. It should be > Obsoletes: transmission < 1.80-0.3.b4 The obsolete version Ive mentioned is the latest stable version fedora is using. the rest are still in testing and can be stopped from going stable. Thank you for your interest :) regards, Ankur
hi, new spec http://ankursinha.fedorapeople.org/transmission/transmission.spec - base package is same - cli package made separately I havent added the webui to the cli, since the daemon can be controlled from the command using transmission-remote too. Someone whose not using X will not have a browser to access the webui. regards, Ankur
One note: -common was suggested because Transmission also has a Qt frontend which is not being built at the moment but as part of this effort, you could also look into that.
(In reply to comment #8) > > As Jussi Lehtola already pointed out: the base package doesn't need to contain > > any files at -- it could just become a meta-package and require all the others, > > Why i havent removed the %files for the base package: > > Removing the %files section means no rpm package named "transmission" being > created. Since folks are still going to be using "yum update transmission", I > cannot allow that to happen. It would break the update path. (please correct me > if I'm wrong here) Yes, you have to have a %files section for the package to be created. However, it can be empty.
Also, the obsoletes should be against the latest version in Rawhide since this is being pushed into Rawhide and not Fedora stable.
I'm not sure I know enough about the spec files to review them intelligently, but Rahul has asked me to weigh in on this. My advice is that third-party/, libtransmission/, and web/ all be packaged in a "common" package that the cli, gtk, qt, and daemon packages could all have as a dependency. Anything using libtransmission can serve up the web ui, so it makes sense to bundle the html/js/css/etc with the "common" package.
FYI, Charles is the primary developer of transmission and we should consider his input seriously.
After lots of discussions with Rex Dieter for general advice and building the Qt interface as well, take a look at http://sundaram.fedorapeople.org/packages/transmission.spec http://sundaram.fedorapeople.org/packages/transmission-1.80-0.4.b4.fc13.src.rpm
I am planning to commit this in a day or two. So please review and let me know if you have any specific feedback.
Are you planning to release it even for F12?
Only in Rawhide for now, initially. I need to test the migration path and 1.80 which is the version in Rawhide is still in Beta. 1.80 however fixes a few important and regularly reported crashes and I might push the stable release once it is available into Fedora 12 and Fedora 11 after letting it into Rawhide first.
Hello, the last spec looks OK to me. I still think that separating -common -cli and -deamon is too fine granularity -- the space saved by the separate one-command packages is almost none. I understand that somebody might like your solution better and I actually care only about getting rid of the X dependencies for the daemon which is achieved. Thank you.
Thanks to Ankur Sinha for working on this. Build completed for Rawhide at http://koji.fedoraproject.org/koji/taskinfo?taskID=1913561 It should hit the repository in a day. I will leave this RFE open for now. I intend to push split up 1.80 packages to Fedora 12 and Fedora 11 when upstream releases it based on feedback in Rawhide. Thanks to Charles Kerr for his fix upstream for making the current head build against Fedora 11.
transmission-1.80-0.5.b5.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/transmission-1.80-0.5.b5.fc12
transmission-1.80-0.5.b5.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update transmission'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0615
transmission-1.80-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/transmission-1.80-1.fc12
transmission-1.80-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/transmission-1.80-1.fc11
transmission-1.80-1.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update transmission'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-0917
transmission-1.80-1.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update transmission'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0922
There are still some kinks to work out in the new packaging of transmission. See bug 563984 comment 2 and [1] for details. The same problem is also reported in bug 556007 and bug 564415. [1] https://admin.fedoraproject.org/updates/F12/FEDORA-2010-1521
I have already responded to those comments You are getting confused with meta package and sub packages
Well, there certainly is confusion. However, I'm afraid it's not mine. Try an actual upgrade from transmission-1.77-1.fc12 and see /usr/bin/transmissioncli and /usr/bin/transmission-daemon disappear. Is that intentional? Me thinks not. ;-) Can someone reopen this bug, please? It's obviously not resolved.
It is very much intentional as I have already explained to you and if a user wants the cli or the daemon they are free to install the specific sub package and that's the whole point of the split