[Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils

[Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils

[Daniel P. Berrange]

I was investigating how to build latest QEMU with the iSCSI block driver
enabled. I saw that configure wanted a libiscsi.so, so I installed that
library from Fedora RPMs via the iscsi-initiator-utils package, but it
still wouldn't build.

After further investigation, I find that QEMU in fact wants a completely
different, unlreated libiscsi.so library:

  https://github.com/sahlberg/libiscsi

Obviously we have a problem here because we can't have two different
libraries called libiscsi.so installed at the same time.

Since iscsi-initiator-utils is a standard Linux distro package whose usage
of libiscsi.so predates this github project, it seems that to resolve this
it will be neccessary to rename the latter. eg perhaps libiscsi-client.so ?

The followup question is where to find actual libiscsi releases to package
up for OS distros ? It is not very desirable to just package GIT snapshots.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils

[ronnie sahlberg]

Yes,

Very unfortuante since libiscsi is such a nice name for a
multiplatform library what even works on win32 :-(

I have so renamed it to libiscsiclient  and sent a patch to qemu to
this list to use -liscsiclient instead of -liscsi



tarballs  can be found at
https://github.com/sahlberg/libiscsi/downloads


That resolves all issues you are concerned about ?


regards
ronnie sahlberg

On Tue, Feb 14, 2012 at 12:24 AM, Daniel P. Berrange
<berrange@redhat.com> wrote:
> I was investigating how to build latest QEMU with the iSCSI block driver
> enabled. I saw that configure wanted a libiscsi.so, so I installed that
> library from Fedora RPMs via the iscsi-initiator-utils package, but it
> still wouldn't build.
>
> After further investigation, I find that QEMU in fact wants a completely
> different, unlreated libiscsi.so library:
>
>  https://github.com/sahlberg/libiscsi
>
> Obviously we have a problem here because we can't have two different
> libraries called libiscsi.so installed at the same time.
>
> Since iscsi-initiator-utils is a standard Linux distro package whose usage
> of libiscsi.so predates this github project, it seems that to resolve this
> it will be neccessary to rename the latter. eg perhaps libiscsi-client.so ?
>
> The followup question is where to find actual libiscsi releases to package
> up for OS distros ? It is not very desirable to just package GIT snapshots.
>
> Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils

[Andreas Färber]

Am 03.03.2012 07:43, schrieb ronnie sahlberg:
> Yes,
> 
> Very unfortuante since libiscsi is such a nice name for a
> multiplatform library what even works on win32 :-(
> 
> I have so renamed it to libiscsiclient  and sent a patch to qemu to
> this list to use -liscsiclient instead of -liscsi

Mind letting us know which library exactly this clashes with (URL)?
According to Hannes there was no clash on openSUSE (which I would call a
standard Linux distro as well), so it sounded like a Fedora-specific
packaging problem to him.

Andreas

> tarballs  can be found at
> https://github.com/sahlberg/libiscsi/downloads
> 
> 
> That resolves all issues you are concerned about ?
> 
> 
> regards
> ronnie sahlberg
> 
> On Tue, Feb 14, 2012 at 12:24 AM, Daniel P. Berrange
> <berrange@redhat.com> wrote:
>> I was investigating how to build latest QEMU with the iSCSI block driver
>> enabled. I saw that configure wanted a libiscsi.so, so I installed that
>> library from Fedora RPMs via the iscsi-initiator-utils package, but it
>> still wouldn't build.
>>
>> After further investigation, I find that QEMU in fact wants a completely
>> different, unlreated libiscsi.so library:
>>
>>  https://github.com/sahlberg/libiscsi
>>
>> Obviously we have a problem here because we can't have two different
>> libraries called libiscsi.so installed at the same time.
>>
>> Since iscsi-initiator-utils is a standard Linux distro package whose usage
>> of libiscsi.so predates this github project, it seems that to resolve this
>> it will be neccessary to rename the latter. eg perhaps libiscsi-client.so ?
>>
>> The followup question is where to find actual libiscsi releases to package
>> up for OS distros ? It is not very desirable to just package GIT snapshots.
>>
>> Regards,
>> Daniel
>> --
>> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
>> |: http://libvirt.org              -o-             http://virt-manager.org :|
>> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
>> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils

[Michael Tokarev]

On 03.03.2012 15:15, Andreas Färber wrote:
> Am 03.03.2012 07:43, schrieb ronnie sahlberg:
>> Yes,
>>
>> Very unfortuante since libiscsi is such a nice name for a
>> multiplatform library what even works on win32 :-(
>>
>> I have so renamed it to libiscsiclient  and sent a patch to qemu to
>> this list to use -liscsiclient instead of -liscsi
> 
> Mind letting us know which library exactly this clashes with (URL)?
> According to Hannes there was no clash on openSUSE (which I would call a
> standard Linux distro as well), so it sounded like a Fedora-specific
> packaging problem to him.

It looks like iscsi-initiator-utils package in fedora is built using
shared libiscsi which appears to be package-specific, e.g.
http://www.rpmseek.com/rpm/iscsi-initiator-utils-6.2.0.870-13.fc13.x86_64.html?hl=com&cx=0:-:0:8107228:0:0:0:

Files:
/sbin/iscsi-iname
/sbin/iscsiadm
/sbin/iscsid
/sbin/iscsistart
/usr/lib64/libiscsi.so.0
...

I'd rename _that_ library to be libiscsi-initiator-utils.so, to
reflect the name of the package in question, since it - again -
_appears_ to be package-specific.


Thanks,

/mjt

>> tarballs  can be found at
>> https://github.com/sahlberg/libiscsi/downloads
>>
>>
>> That resolves all issues you are concerned about ?
>>
>>
>> regards
>> ronnie sahlberg
>>
>> On Tue, Feb 14, 2012 at 12:24 AM, Daniel P. Berrange
>> <berrange@redhat.com> wrote:
>>> I was investigating how to build latest QEMU with the iSCSI block driver
>>> enabled. I saw that configure wanted a libiscsi.so, so I installed that
>>> library from Fedora RPMs via the iscsi-initiator-utils package, but it
>>> still wouldn't build.
>>>
>>> After further investigation, I find that QEMU in fact wants a completely
>>> different, unlreated libiscsi.so library:
>>>
>>>  https://github.com/sahlberg/libiscsi
>>>
>>> Obviously we have a problem here because we can't have two different
>>> libraries called libiscsi.so installed at the same time.
>>>
>>> Since iscsi-initiator-utils is a standard Linux distro package whose usage
>>> of libiscsi.so predates this github project, it seems that to resolve this
>>> it will be neccessary to rename the latter. eg perhaps libiscsi-client.so ?
>>>
>>> The followup question is where to find actual libiscsi releases to package
>>> up for OS distros ? It is not very desirable to just package GIT snapshots.
>>>
>>> Regards,
>>> Daniel
>>> --
>>> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
>>> |: http://libvirt.org              -o-             http://virt-manager.org :|
>>> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
>>> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
> 

Re: [Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils

[Daniel P. Berrange]

On Sat, Mar 03, 2012 at 05:43:48PM +1100, ronnie sahlberg wrote:
> Yes,
> 
> Very unfortuante since libiscsi is such a nice name for a
> multiplatform library what even works on win32 :-(
> 
> I have so renamed it to libiscsiclient  and sent a patch to qemu to
> this list to use -liscsiclient instead of -liscsi
> 
> 
> 
> tarballs  can be found at
> https://github.com/sahlberg/libiscsi/downloads
> 
> 
> That resolves all issues you are concerned about ?

Yes, thankyou, that should be fine now. I plan to get this into Fedora
in the not too distant future now.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils

[Daniel P. Berrange]

On Sat, Mar 03, 2012 at 03:54:19PM +0400, Michael Tokarev wrote:
> On 03.03.2012 15:15, Andreas Färber wrote:
> > Am 03.03.2012 07:43, schrieb ronnie sahlberg:
> >> Yes,
> >>
> >> Very unfortuante since libiscsi is such a nice name for a
> >> multiplatform library what even works on win32 :-(
> >>
> >> I have so renamed it to libiscsiclient  and sent a patch to qemu to
> >> this list to use -liscsiclient instead of -liscsi
> > 
> > Mind letting us know which library exactly this clashes with (URL)?
> > According to Hannes there was no clash on openSUSE (which I would call a
> > standard Linux distro as well), so it sounded like a Fedora-specific
> > packaging problem to him.
> 
> It looks like iscsi-initiator-utils package in fedora is built using
> shared libiscsi which appears to be package-specific, e.g.

Yes, it is the iscsi-initiator-utils package

> I'd rename _that_ library to be libiscsi-initiator-utils.so, to
> reflect the name of the package in question, since it - again -
> _appears_ to be package-specific.

That's not really practical at this time, since it has been shipped this
way for years now, and in any case ronnie has already been good enough
to rename to libiscsiclient to avoid the potential ambiguity.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils

[Michael Tokarev]

On 06.03.2012 14:07, Daniel P. Berrange wrote:
> On Sat, Mar 03, 2012 at 03:54:19PM +0400, Michael Tokarev wrote:
>> It looks like iscsi-initiator-utils package in fedora is built using
>> shared libiscsi which appears to be package-specific, e.g.
> 
> Yes, it is the iscsi-initiator-utils package
> 
>> I'd rename _that_ library to be libiscsi-initiator-utils.so, to
>> reflect the name of the package in question, since it - again -
>> _appears_ to be package-specific.
> 
> That's not really practical at this time, since it has been shipped this
> way for years now,

Why it is not practical for something which is not used for
anything but just the internal library?  I'd say it was a
mistake to name this internal library this way to start
with, and now it is as good time to do so as any other time,
because, again, it is just some internal-to-the-package thing.

>          and in any case ronnie has already been good enough
> to rename to libiscsiclient to avoid the potential ambiguity.

Now the resulting libiscsiclient has alot of _real_ ambiguity,
unfortunately.

/mjt

Re: [Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils

[ronnie sahlberg]

Sorry about this.

First, libiscsi is a really good name for a general purpose
multiplatform library, like libiscsi.
Second,  a generic name like this is a horribly poor idea for a single
distribution/ single use / obscure private library.


I want to solve a problem  to make it available on all platforms.
I dont like to chose a suboptimal name for this reason,  but I thought
I had no choice.


I am not really excited with the concept of "obscure single use
private library polluting the namespace like this" but what are my
options ?
I can live with renaming my library if that is what it takes.


What do you want me to do ?
Tell me and I will do it.



regards
ronnie sahlberg


On Tue, Mar 6, 2012 at 9:38 PM, Michael Tokarev <mjt@tls.msk.ru> wrote:
> On 06.03.2012 14:07, Daniel P. Berrange wrote:
>> On Sat, Mar 03, 2012 at 03:54:19PM +0400, Michael Tokarev wrote:
>>> It looks like iscsi-initiator-utils package in fedora is built using
>>> shared libiscsi which appears to be package-specific, e.g.
>>
>> Yes, it is the iscsi-initiator-utils package
>>
>>> I'd rename _that_ library to be libiscsi-initiator-utils.so, to
>>> reflect the name of the package in question, since it - again -
>>> _appears_ to be package-specific.
>>
>> That's not really practical at this time, since it has been shipped this
>> way for years now,
>
> Why it is not practical for something which is not used for
> anything but just the internal library?  I'd say it was a
> mistake to name this internal library this way to start
> with, and now it is as good time to do so as any other time,
> because, again, it is just some internal-to-the-package thing.
>
>>          and in any case ronnie has already been good enough
>> to rename to libiscsiclient to avoid the potential ambiguity.
>
> Now the resulting libiscsiclient has alot of _real_ ambiguity,
> unfortunately.
>
> /mjt

Re: [Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils

[Daniel P. Berrange]

On Tue, Mar 06, 2012 at 10:06:38PM +1100, ronnie sahlberg wrote:
> Sorry about this.
> 
> First, libiscsi is a really good name for a general purpose
> multiplatform library, like libiscsi.
> Second,  a generic name like this is a horribly poor idea for a single
> distribution/ single use / obscure private library.

Yes, I agree it was a bad idea for the Fedora/RHEL admin to have done
this for iscsi-initiator-utils packaging. Now this exists though, the
library name & ABI has to be maintained in RHEL for back-compatibility,
so sadly we can't easily fix this. At the same time I really want to
include your iSCSI support in Fedora/RHEL.

So, IMHO, the simplest approach is to just avoid the namespace clash
by calling your library  libiscsiclient

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils

[Hannes Reinecke]

On 03/06/2012 12:06 PM, ronnie sahlberg wrote:
> Sorry about this.
> 
> First, libiscsi is a really good name for a general purpose
> multiplatform library, like libiscsi.
> Second,  a generic name like this is a horribly poor idea for a single
> distribution/ single use / obscure private library.
> 
Yes.

> 
> I want to solve a problem  to make it available on all platforms.
> I dont like to chose a suboptimal name for this reason,  but I thought
> I had no choice.
> 
Fully agreed. I'm perfectly fine with libiscsi ...

> 
> I am not really excited with the concept of "obscure single use
> private library polluting the namespace like this" but what are my
> options ?
> I can live with renaming my library if that is what it takes.
> 
IMO the only sane option here is to have a separate package,
containing libiscsi _only_.

It can be a sub-package of existing iscsi-related things, ie
contained within the existing open-iscsi _source_ repository.

But having is packaged _together_ with another rpm is really bad.
Plus it makes updating a nightmare.

So, Mike, what about having it as a sub-package to open-iscsi?
I'm all for it, especially as some partners are already asking for
it ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

Re: [Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils

[Michael Tokarev]

06.03.2012 15:15, Daniel P. Berrange wrote:
> On Tue, Mar 06, 2012 at 10:06:38PM +1100, ronnie sahlberg wrote:
>> Sorry about this.
>>
>> First, libiscsi is a really good name for a general purpose
>> multiplatform library, like libiscsi.
>> Second,  a generic name like this is a horribly poor idea for a single
>> distribution/ single use / obscure private library.
>
> Yes, I agree it was a bad idea for the Fedora/RHEL admin to have done
> this for iscsi-initiator-utils packaging. Now this exists though, the
> library name&  ABI has to be maintained in RHEL for back-compatibility,
> so sadly we can't easily fix this. At the same time I really want to
> include your iSCSI support in Fedora/RHEL.

Which ABI you're talking about?  The library is _internal_ to the package,
there should be no users of it outside of this single set of utilities.
Can you be a bit more specific please?

> So, IMHO, the simplest approach is to just avoid the namespace clash
> by calling your library  libiscsiclient

Thanks,

/mjt

Re: [Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils

[Mike Christie]

On 03/06/2012 06:19 AM, Hannes Reinecke wrote:
> On 03/06/2012 12:06 PM, ronnie sahlberg wrote:
>> Sorry about this.
>>
>> First, libiscsi is a really good name for a general purpose
>> multiplatform library, like libiscsi.
>> Second,  a generic name like this is a horribly poor idea for a single
>> distribution/ single use / obscure private library.
>>
> Yes.
> 
>>
>> I want to solve a problem  to make it available on all platforms.
>> I dont like to chose a suboptimal name for this reason,  but I thought
>> I had no choice.
>>
> Fully agreed. I'm perfectly fine with libiscsi ...
> 
>>
>> I am not really excited with the concept of "obscure single use
>> private library polluting the namespace like this" but what are my
>> options ?
>> I can live with renaming my library if that is what it takes.
>>
> IMO the only sane option here is to have a separate package,
> containing libiscsi _only_.
> 
> It can be a sub-package of existing iscsi-related things, ie
> contained within the existing open-iscsi _source_ repository.
> 
> But having is packaged _together_ with another rpm is really bad.
> Plus it makes updating a nightmare.
> 
> So, Mike, what about having it as a sub-package to open-iscsi?
> I'm all for it, especially as some partners are already asking for
> it ...
> 

Not sure what we are talking about. Are you talking about the libiscsi
that ships in fedora/rhel? That comes in the iscsi-initiator-utils-devel
rpm already. It should not get installed with just the
iscsi-initiator-utils rpm.

That lib really should only be used by anaconda. That lib is not a good
general purpose lib. It is kinda awkward. Some of the iscsi concepts are
mixed up. My preference is that only anaconda ever uses that lib,
because I am not supporting it upstream. It is not merged upstream for
example. The upstream iscsi tools do not use it (anaconda people
actually wrote it so it works for them, but it does not work for
iscsiadm for example). I only support it for rhel/fedora for anaconda use.

Re: [Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils

[Mike Christie]

On 03/06/2012 01:58 PM, Mike Christie wrote:
> On 03/06/2012 06:19 AM, Hannes Reinecke wrote:
>> On 03/06/2012 12:06 PM, ronnie sahlberg wrote:
>>> Sorry about this.
>>>
>>> First, libiscsi is a really good name for a general purpose
>>> multiplatform library, like libiscsi.
>>> Second,  a generic name like this is a horribly poor idea for a single
>>> distribution/ single use / obscure private library.
>>>
>> Yes.
>>
>>>
>>> I want to solve a problem  to make it available on all platforms.
>>> I dont like to chose a suboptimal name for this reason,  but I thought
>>> I had no choice.
>>>
>> Fully agreed. I'm perfectly fine with libiscsi ...
>>
>>>
>>> I am not really excited with the concept of "obscure single use
>>> private library polluting the namespace like this" but what are my
>>> options ?
>>> I can live with renaming my library if that is what it takes.
>>>
>> IMO the only sane option here is to have a separate package,
>> containing libiscsi _only_.
>>
>> It can be a sub-package of existing iscsi-related things, ie
>> contained within the existing open-iscsi _source_ repository.
>>
>> But having is packaged _together_ with another rpm is really bad.
>> Plus it makes updating a nightmare.
>>
>> So, Mike, what about having it as a sub-package to open-iscsi?
>> I'm all for it, especially as some partners are already asking for
>> it ...
>>
> 
> Not sure what we are talking about. Are you talking about the libiscsi
> that ships in fedora/rhel? That comes in the iscsi-initiator-utils-devel
> rpm already. It should not get installed with just the
> iscsi-initiator-utils rpm.
> 
> That lib really should only be used by anaconda. That lib is not a good
> general purpose lib. It is kinda awkward. Some of the iscsi concepts are
> mixed up. My preference is that only anaconda ever uses that lib,
> because I am not supporting it upstream. It is not merged upstream for
> example. The upstream iscsi tools do not use it (anaconda people
> actually wrote it so it works for them, but it does not work for
> iscsiadm for example). I only support it for rhel/fedora for anaconda use.


Oh yeah, if the libiscsi from iscsi-initiator-utils-devel is causing
naming conflicts then I am fine with renaming that to something else if
that fixes the issue.

Re: [Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils

[ronnie sahlberg]

Hi Mike,

Thanks!

That would be great if you rename it to something less generic and
specific to libiscsi-utils.
That means I can continue using libiscsi as the name for my
multiplatform library.

By the way,  if the only user today and in the future of the library
in libiscsi-utils is anaconda,
what features do you need in anaconda. Maybe I can add them to the
github.com/sahlberg/libiscsi.git library ?

regards
ronnie sahlberg



On Wed, Mar 7, 2012 at 7:13 AM, Mike Christie <michaelc@cs.wisc.edu> wrote:
> On 03/06/2012 01:58 PM, Mike Christie wrote:
>> On 03/06/2012 06:19 AM, Hannes Reinecke wrote:
>>> On 03/06/2012 12:06 PM, ronnie sahlberg wrote:
>>>> Sorry about this.
>>>>
>>>> First, libiscsi is a really good name for a general purpose
>>>> multiplatform library, like libiscsi.
>>>> Second,  a generic name like this is a horribly poor idea for a single
>>>> distribution/ single use / obscure private library.
>>>>
>>> Yes.
>>>
>>>>
>>>> I want to solve a problem  to make it available on all platforms.
>>>> I dont like to chose a suboptimal name for this reason,  but I thought
>>>> I had no choice.
>>>>
>>> Fully agreed. I'm perfectly fine with libiscsi ...
>>>
>>>>
>>>> I am not really excited with the concept of "obscure single use
>>>> private library polluting the namespace like this" but what are my
>>>> options ?
>>>> I can live with renaming my library if that is what it takes.
>>>>
>>> IMO the only sane option here is to have a separate package,
>>> containing libiscsi _only_.
>>>
>>> It can be a sub-package of existing iscsi-related things, ie
>>> contained within the existing open-iscsi _source_ repository.
>>>
>>> But having is packaged _together_ with another rpm is really bad.
>>> Plus it makes updating a nightmare.
>>>
>>> So, Mike, what about having it as a sub-package to open-iscsi?
>>> I'm all for it, especially as some partners are already asking for
>>> it ...
>>>
>>
>> Not sure what we are talking about. Are you talking about the libiscsi
>> that ships in fedora/rhel? That comes in the iscsi-initiator-utils-devel
>> rpm already. It should not get installed with just the
>> iscsi-initiator-utils rpm.
>>
>> That lib really should only be used by anaconda. That lib is not a good
>> general purpose lib. It is kinda awkward. Some of the iscsi concepts are
>> mixed up. My preference is that only anaconda ever uses that lib,
>> because I am not supporting it upstream. It is not merged upstream for
>> example. The upstream iscsi tools do not use it (anaconda people
>> actually wrote it so it works for them, but it does not work for
>> iscsiadm for example). I only support it for rhel/fedora for anaconda use.
>
>
> Oh yeah, if the libiscsi from iscsi-initiator-utils-devel is causing
> naming conflicts then I am fine with renaming that to something else if
> that fixes the issue.

Re: [Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils

[Mike Christie]

On 03/06/2012 07:51 PM, ronnie sahlberg wrote:
> Hi Mike,
> 
> Thanks!
> 
> That would be great if you rename it to something less generic and
> specific to libiscsi-utils.
> That means I can continue using libiscsi as the name for my
> multiplatform library.
> 
> By the way,  if the only user today and in the future of the library
> in libiscsi-utils is anaconda,

The only current user that I know of is anaconda, but I have been
working on making a more generic lib that others can use. I think Qlogic
was going to use it too, but I have been trying to advise them not to
since it was not upstream.

For anaconda we need to be able to find targets/disks and setup the
install on them. We want to then set things up so the OS uses those
disks and whatever driver (software iscsi or one of the offload drivers
or iser) they selected for root/boot and the other partitions.

In general, I just want to have a way to login, discover, and manage
targets and HBAs using the software iscsi or iser driver or one of the
offload cards we support. So something like IMA. I wanted to keep it
close to IMA so other vendors can use it for a plugin if needed.

If your lib can or would like to do stuff like that, I would be very
very very happy :)