| Summary: | Split to iodine-client and iodine-server | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jan Kratochvil <jan.kratochvil> |
| Component: | iodine | Assignee: | Pavel Alexeev <pahan> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | jan.kratochvil, lystor, pahan |
| Target Milestone: | --- | Keywords: | FutureFeature, Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-01-08 19:29:41 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Sorry, but "wasteful" what?? There two small files. We speak about it on review process and I had not seen any advantages of splitting. Configs named differently, why it confuses you? When I am logged on two consoles into two hosts I have 4 sets of config files available to edit. 2 sets of those are dead - unused. This is confusing. If you threat it unused why you couldn't delete it? I really don't understand problem. (In reply to comment #3) > If you threat it unused why you couldn't delete it? # rm /etc/rc.d/init.d/iodine-server /etc/sysconfig/iodine-server /usr/sbin/iodined /etc/logrotate.d/iodine # rpm -V iodine missing c /etc/logrotate.d/iodine missing /etc/rc.d/init.d/iodine-server missing c /etc/sysconfig/iodine-server missing /usr/sbin/iodined And on next yum update the files will be back. +I find it inconvenient everyone has to delete first part of the package on one host and the second part on the other host. > I really don't understand problem. There is also openssh-server and openssh-clients. Do you recomment merging them? Why to care about some sshd server and its keys on a host which I use only as a client? I just do not install openssh-server there and I am done. (In reply to comment #4) > (In reply to comment #3) > > If you threat it unused why you couldn't delete it? > And on next yum update the files will be back. Have you seen many updates of iodine? If you very wish you could revoke write rights on that config directory. > > I really don't understand problem. > There is also openssh-server and openssh-clients. Do you recomment merging > them? No, it just theirs choose. But there also openvpn which single package. Why you do not insist to split it? (Off course it is example and there many other similar thinks) (In reply to comment #5) > Have you seen many updates of iodine? For example on each mass rebuild which is going to happen soon. > If you very wish you could revoke write rights on that config directory. I spent my time on improving the package, if you really try to prove it casn be kept worse, sure it can. I am no longer going to spend my time on this Bug, I can spend it more useful on other Free packages. > But there also openvpn which single package. Why you do not insist to split > it? How do you want to split openvpn? Its binaries + configs are like for peer-to-peer setup, server/client is only a configuration option there. Ok, Jan. I still do not see any advantages of it, but you second requester and you really spent many time on that discussion... I going to split it. Please check rawhide build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3614723 The package iodine-0.6.0-0.rc1.7.fc17 should not exist, just make a copy of /usr/share/doc/iodine-0.6.0 into both iodine-client and iodine-server. That works fine even if you install both iodine-client and iodine-server. /usr/share/man/man8/iodine.8.gz should also be present as: /usr/share/man/man8/iodined.8.gz in the iodine-server package and its content should be split. This part should be also split upstream. I am not aware why it is merged. I do not see how it works during upgrade, IMO it does not. If one has iodine-0.6.0-0.rc1.6.fc15.1.x86_64 installed it should automatically install during upgrade to F-17 both iodine-client and iodine-server. Maybe an empty iodine package is needed which Requires: iodine-client iodine-server and that empty iodine package could be removed for F-19. Or is there a better solution? Otherwise it looks great - each of the two packages is very simple now, thanks. I have not tested this version but it is also not the final variant I guess. I can do some of the work if it looks as too much burden for you. (In reply to comment #9) > The package iodine-0.6.0-0.rc1.7.fc17 should not exist Is metapackage mean "all", as it was before. It should exists. > /usr/share/man/man8/iodine.8.gz should also be present as: > /usr/share/man/man8/iodined.8.gz in the iodine-server package and its content > should be split. This part should be also split upstream. I am not aware why > it is merged. I think it wasn't merged, it born as one project, one packet. If you are willing split it (I agree it is good idea as we split packages) - you help will be hepful. > I do not see how it works during upgrade, IMO it does not. If one has > iodine-0.6.0-0.rc1.6.fc15.1.x86_64 installed it should automatically install > during upgrade to F-17 both iodine-client and iodine-server. Maybe an empty > iodine package is needed which > Requires: iodine-client iodine-server > and that empty iodine package could be removed for F-19. Or is there a better > solution? It is a current, just iodine require both client and server. Why you think it shouldn't work? I suppose it should. > Otherwise it looks great - each of the two packages is very simple now, thanks. > I have not tested this version but it is also not the final variant I guess. > > I can do some of the work if it looks as too much burden for you. All help will be appreciated, at least testing. (In reply to comment #10) > (In reply to comment #9) > > The package iodine-0.6.0-0.rc1.7.fc17 should not exist > Is metapackage mean "all", as it was before. It should exists. I disagree but it is your package. > If you are willing split it (I agree it is good idea as we split packages) > - you help will be hepful. Posted: [iodine-users] [patch] Split the man page -> iodine(8) / iodined(8) http://lists.wpkg.org/pipermail/iodine-users/2012-January/000065.html > It is a current, just iodine require both client and server. Why you think it > shouldn't work? I suppose it should. After you move out the /usr/share/doc/iodine-0.6.0/ files out of iodine into iodine-client and iodine-server packages the iodine package itself will remain empty. If you want to keep thue empty iodine package I am fine with it and the upgrade path will work. We can discuss it again for F-19 as the upgrade path will no longer be meaningful there. > All help will be appreciated, at least testing. iodine-server works fully OK (with my Nokia 900's iodine). I could not fully test (easily enough) Fedora iodine-client but according to everything it also looks the packaging part is OK. BTW it should switch from /etc/init.d to systemd but that is outside of the scope of this Bug. Thanks. (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > The package iodine-0.6.0-0.rc1.7.fc17 should not exist > > Is metapackage mean "all", as it was before. It should exists. > > I disagree but it is your package. It also proper solution to migrate! Please note, nor client or server require meta-package back! So, it satisfied all usages. > > > If you are willing split it (I agree it is good idea as we split packages) > > - you help will be hepful. > > Posted: > [iodine-users] [patch] Split the man page -> iodine(8) / iodined(8) > http://lists.wpkg.org/pipermail/iodine-users/2012-January/000065.html Thank you. Patch included. > > It is a current, just iodine require both client and server. Why you think it > > shouldn't work? I suppose it should. > > After you move out the /usr/share/doc/iodine-0.6.0/ files out of iodine into > iodine-client and iodine-server packages the iodine package itself will remain > empty. I leave doc files CHANGELOG README TODO in base meta-package as you may see. So, it is not empty. > BTW it should switch from /etc/init.d to systemd Ehh, yes, there you right. > but that is outside of the > scope of this Bug. And it also absolutely correct! Thank you for the help. http://koji.fedoraproject.org/koji/taskinfo?taskID=3630323 (In reply to comment #12) > (In reply to comment #11) > > After you move out the /usr/share/doc/iodine-0.6.0/ files out of iodine into > > iodine-client and iodine-server packages the iodine package itself will remain > > empty. > > I leave doc files CHANGELOG README TODO in base meta-package as you may see. > So, it is not empty. In such case you should rather WONTFIX this Bug as it whole does not make sense then. To have valid installation of iodine-server I need also /usr/share/doc/iodine*, therefore I have to install also iodine. But iodine will install iodine-client. And I have all the files again, moreover in three(!) packages now. (In reply to comment #13) > In such case you should rather WONTFIX this Bug as it whole does not make sense > then. To have valid installation of iodine-server I need also > /usr/share/doc/iodine* Sorry, I did not understand what you are mean under "valid installation"? iodine-server package fully functional without iodine or iodine-client. There even no copying information to copy it across packages by our guidelines. When I install only iodine-server I do not have any information in /usr/share/doc/iodine-server-*/. For every other normal package I have the associated information in /usr/share/doc/iodine-server-*/. If I want to look at the CHANGELOG/README/TODO/etc. files I have to install the base iodine package in your layout which will install the other client/server part which I did not want, and we are where we were before filing this Bug. ISTM you still do not share the idea of two separate packages, making something half-separate is not a separation. There no any useful information at all. It have not worth to split into separate -doc subpackage. If you want do not install client package and look into TODO iodine file - you may do it in internet or tarball. (In reply to comment #16) > There no any useful information at all. In such case you should drop the files completely. > It have not worth to split into separate -doc subpackage. I agree. This is why it should be in iodine-client and iodine-server. > If you want do not install client package and look > into TODO iodine file - you may do it in internet or tarball. Looking at Internet or tarball is a failure of the packaging process. It absolutely have no worth duplicate such non-requirement files. Ok, I had add also in meta-package description what it contain also such files. |
Description of problem: Currently one has to install both client and server. (a) This is "wasteful", one usually does not have a machine acting as both client and server. (b) This is confusing, when configuring both the client host and server host one easily mistakes the client vs. server config/deaemon on the client vs. server host. Version-Release number of selected component (if applicable): iodine-0.6.0-0.rc1.6.fc15.1.x86_64 How reproducible: Always. Steps to Reproduce: yum install /usr/sbin/iodine ls /usr/sbin/iodined Actual results: /usr/sbin/iodined* Expected results: ls: cannot access /usr/sbin/iodined: No such file or directory Additional info: Some backward compatibility rpm tags should be used so that one still gets both iodine-client and iodine-server packages when there was installed iodine before.