qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mike Christie
Subject: Re: [Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils
Date: Tue, 06 Mar 2012 14:13:48 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]