Bug 758930 - Split to iodine-client and iodine-server
Summary: Split to iodine-client and iodine-server
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: iodine
Version: rawhide
Hardware: Unspecified
OS: Linux
low
low
Target Milestone: ---
Assignee: Pavel Alexeev
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-01 01:15 UTC by Jan Kratochvil
Modified: 2012-01-08 19:29 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-08 19:29:41 UTC
Type: ---


Attachments (Terms of Use)

Description Jan Kratochvil 2011-12-01 01:15:30 UTC
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.

Comment 1 Pavel Alexeev 2011-12-11 20:29:25 UTC
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?

Comment 2 Jan Kratochvil 2011-12-11 20:34:19 UTC
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.

Comment 3 Pavel Alexeev 2011-12-31 17:28:05 UTC
If you threat it unused why you couldn't delete it?
I really don't understand problem.

Comment 4 Jan Kratochvil 2012-01-01 12:48:49 UTC
(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.

Comment 5 Pavel Alexeev 2012-01-02 10:00:32 UTC
(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)

Comment 6 Jan Kratochvil 2012-01-02 10:11:52 UTC
(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.

Comment 7 Pavel Alexeev 2012-01-02 10:37:42 UTC
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.

Comment 8 Pavel Alexeev 2012-01-02 19:44:57 UTC
Please check rawhide build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3614723

Comment 9 Jan Kratochvil 2012-01-02 21:45:32 UTC
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.

Comment 10 Pavel Alexeev 2012-01-06 18:55:57 UTC
(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.

Comment 11 Jan Kratochvil 2012-01-08 14:10:32 UTC
(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.

Comment 12 Pavel Alexeev 2012-01-08 17:34:51 UTC
(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

Comment 13 Jan Kratochvil 2012-01-08 17:53:20 UTC
(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.

Comment 14 Pavel Alexeev 2012-01-08 18:13:46 UTC
(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.

Comment 15 Jan Kratochvil 2012-01-08 18:56:39 UTC
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.

Comment 16 Pavel Alexeev 2012-01-08 19:04:14 UTC
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.

Comment 17 Jan Kratochvil 2012-01-08 19:06:46 UTC
(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.

Comment 18 Pavel Alexeev 2012-01-08 19:29:41 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.