refactored packages cause conflict/dependency issue

[Xavier Toth]

I previously had a package in which rolled up a number of shared
libraries. Now I've placed one of the shared libraries in its own
package. So now the shared library package no longer provides I'll
call it libx.so and the new package does. Other installed packages
depend on the libx.so shared library. When I try and update the shared
library package it fails because of the dependency of other packages
on the shared library that it previously provided. Also if I try and
install the new package it fails because of the conflict with the
shared library package over the providing of libx.so. What is the
correct way to handle such a situation? I'd prefer not to resort to
--force or --replacefiles.

[Matthew Miller]

On Thu, Jun 21, 2007 at 12:13:37PM -0500, Xavier Toth wrote:
> I previously had a package in which rolled up a number of shared
> libraries. Now I've placed one of the shared libraries in its own
> package. So now the shared library package no longer provides I'll
> call it libx.so and the new package does. Other installed packages
> depend on the libx.so shared library. When I try and update the shared
> library package it fails because of the dependency of other packages
> on the shared library that it previously provided. Also if I try and
> install the new package it fails because of the conflict with the
> shared library package over the providing of libx.so. What is the
> correct way to handle such a situation? I'd prefer not to resort to
> --force or --replacefiles.

Install both of your new packages at the same time.

--
Matthew Miller ***@mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>

[Xavier Toth]

I tried doing:
rpm -Uvh rolledup-libs.rpm libx.rpm
but this failed because of the dependencies of existing packages. I'm
guessing but I think that when rpm tries to uninstall the previous rev
of rolledup-libs it does the dependency check and says I can't remove
libx.so because other packages need it.

On 6/21/07, Matthew Miller <***@mattdm.org> wrote:
> On Thu, Jun 21, 2007 at 12:13:37PM -0500, Xavier Toth wrote:
> > I previously had a package in which rolled up a number of shared
> > libraries. Now I've placed one of the shared libraries in its own
> > package. So now the shared library package no longer provides I'll
> > call it libx.so and the new package does. Other installed packages
> > depend on the libx.so shared library. When I try and update the shared
> > library package it fails because of the dependency of other packages
> > on the shared library that it previously provided. Also if I try and
> > install the new package it fails because of the conflict with the
> > shared library package over the providing of libx.so. What is the
> > correct way to handle such a situation? I'd prefer not to resort to
> > --force or --replacefiles.
>
> Install both of your new packages at the same time.
>
> --
> Matthew Miller ***@mattdm.org <http://mattdm.org/>
> Boston University Linux ------> <http://linux.bu.edu/>
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-***@redhat.com
> https://www.redhat.com/mailman/listinfo/rpm-list
>

[Jeff Johnson]

On Jun 21, 2007, at 1:13 PM, Xavier Toth wrote:

> I previously had a package in which rolled up a number of shared
> libraries. Now I've placed one of the shared libraries in its own
> package. So now the shared library package no longer provides I'll
> call it libx.so and the new package does. Other installed packages
> depend on the libx.so shared library. When I try and update the shared
> library package it fails because of the dependency of other packages
> on the shared library that it previously provided. Also if I try and
> install the new package it fails because of the conflict with the
> shared library package over the providing of libx.so. What is the
> correct way to handle such a situation? I'd prefer not to resort to
> --force or --replacefiles.
>

You likely have forgotten the executable bit on the refactored libx.so
library. Otherwise, you need a DT_SONAME in the library.

rpm tries very hard to never automagically extract dependency info for
non-executables.

hth

73 de Jeff

[Xavier Toth]

I've verified that the shared library has it executable mode bits set.

On 6/21/07, Jeff Johnson <***@gmail.com> wrote:
>
> On Jun 21, 2007, at 1:13 PM, Xavier Toth wrote:
>
> > I previously had a package in which rolled up a number of shared
> > libraries. Now I've placed one of the shared libraries in its own
> > package. So now the shared library package no longer provides I'll
> > call it libx.so and the new package does. Other installed packages
> > depend on the libx.so shared library. When I try and update the shared
> > library package it fails because of the dependency of other packages
> > on the shared library that it previously provided. Also if I try and
> > install the new package it fails because of the conflict with the
> > shared library package over the providing of libx.so. What is the
> > correct way to handle such a situation? I'd prefer not to resort to
> > --force or --replacefiles.
> >
>
> You likely have forgotten the executable bit on the refactored libx.so
> library. Otherwise, you need a DT_SONAME in the library.
>
> rpm tries very hard to never automagically extract dependency info for
> non-executables.
>
> hth
>
> 73 de Jeff
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-***@redhat.com
> https://www.redhat.com/mailman/listinfo/rpm-list
>

[Hiren Patel]

try finding out what packages depend on libx.so, remove those packages,
upgrade the package containing the shared libs, install the package
contain the one isolated lib, and then install the packages you removed
that depended on libx.so

On Thu, 2007-06-21 at 12:54 -0500, Xavier Toth wrote:
> I've verified that the shared library has it executable mode bits set.
>
> On 6/21/07, Jeff Johnson <***@gmail.com> wrote:
> >
> > On Jun 21, 2007, at 1:13 PM, Xavier Toth wrote:
> >
> > > I previously had a package in which rolled up a number of shared
> > > libraries. Now I've placed one of the shared libraries in its own
> > > package. So now the shared library package no longer provides I'll
> > > call it libx.so and the new package does. Other installed packages
> > > depend on the libx.so shared library. When I try and update the shared
> > > library package it fails because of the dependency of other packages
> > > on the shared library that it previously provided. Also if I try and
> > > install the new package it fails because of the conflict with the
> > > shared library package over the providing of libx.so. What is the
> > > correct way to handle such a situation? I'd prefer not to resort to
> > > --force or --replacefiles.
> > >
> >
> > You likely have forgotten the executable bit on the refactored libx.so
> > library. Otherwise, you need a DT_SONAME in the library.
> >
> > rpm tries very hard to never automagically extract dependency info for
> > non-executables.
> >
> > hth
> >
> > 73 de Jeff
> >
> > _______________________________________________
> > Rpm-list mailing list
> > Rpm-***@redhat.com
> > https://www.redhat.com/mailman/listinfo/rpm-list
> >
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-***@redhat.com
> https://www.redhat.com/mailman/listinfo/rpm-list
--

Hiren Patel | Ops Specialist | ISS Infrastructure | Telkom
E-Mail: ***@telkom.co.za Office: [phone] | Fax: [phone]
3299 | Cell: [phone]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This e-mail and its contents are subject to the Telkom SA Limited
e-mail legal notice available at
http://www.telkom.co.za/TelkomEMailLegalNotice.PDF
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Xavier Toth]

I agree that this will work but I was hoping for a solution that
wouldn't require this drastic of measures. In my case I've got 80
other packages that are affected and the idea of having to uninstall
and reinstall all of them is not nice to put it mildly.

On 6/22/07, Hiren Patel <***@telkom
> try finding out what packages depend on libx.so, remove those packages,
> upgrade the package containing the shared libs, install the package
> contain the one isolated lib, and then install the packages you removed
> that depended on libx.so
>
> On Thu, 2007-06-21 at 12:54 -0500, Xavier Toth wrote:
> > I've verified that the shared library has it executable mode bits set.
> >
> > On 6/21/07, Jeff Johnson <***@gmail.com> wrote:
> > >
> > > On Jun 21, 2007, at 1:13 PM, Xavier Toth wrote:
> > >
> > > > I previously had a package in which rolled up a number of shared
> > > > libraries. Now I've placed one of the shared libraries in its own
> > > > package. So now the shared library package no longer provides I'll
> > > > call it libx.so and the new package does. Other installed packages
> > > > depend on the libx.so shared library. When I try and update the shared
> > > > library package it fails because of the dependency of other packages
> > > > on the shared library that it previously provided. Also if I try and
> > > > install the new package it fails because of the conflict with the
> > > > shared library package over the providing of libx.so. What is the
> > > > correct way to handle such a situation? I'd prefer not to resort to
> > > > --force or --replacefiles.
> > > >
> > >
> > > You likely have forgotten the executable bit on the refactored libx.so
> > > library. Otherwise, you need a DT_SONAME in the library.
> > >
> > > rpm tries very hard to never automagically extract dependency info for
> > > non-executables.
> > >
> > > hth
> > >
> > > 73 de Jeff
> > >
> > > _______________________________________________
> > > Rpm-list mailing list
> > > Rpm-***@redhat.com
> > > https://www.redhat.com/mailman/listinfo/rpm-list
> > >
> >
> > _______________________________________________
> > Rpm-list mailing list
> > Rpm-***@redhat.com
> > https://www.redhat.com/mailman/listinfo/rpm-list
> --
>
> Hiren Patel | Ops Specialist | ISS Infrastructure | Telkom
> E-Mail: ***@telkom.co.za Office: [phone] | Fax: [phone]
> 3299 | Cell: [phone]
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> This e-mail and its contents are subject to the Telkom SA Limited
> e-mail legal notice available at
> http://www.telkom.co.za/TelkomEMailLegalNotice.PDF
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-***@redhat.com
> https://www.redhat.com/mailman/listinfo/rpm-list
>

[Peter Smith]

Have you given any thought to using the "Obsoletes" tag? I wonder if this is the solution to the problem? Or, have you already come up with one? I was looking carefully at a page that has *some* info which includes it [1].

Peter

[1] http://annvix.org/Documentation/Dev/Building/Specs

>>> "Xavier Toth" <***@gmail.com> 06/23/07 9:27 AM >>>
I agree that this will work but I was hoping for a solution that
wouldn't require this drastic of measures. In my case I've got 80
other packages that are affected and the idea of having to uninstall
and reinstall all of them is not nice to put it mildly.

On 6/22/07, Hiren Patel <***@telkom
> try finding out what packages depend on libx.so, remove those packages,
> upgrade the package containing the shared libs, install the package
> contain the one isolated lib, and then install the packages you removed
> that depended on libx.so
>
> On Thu, 2007-06-21 at 12:54 -0500, Xavier Toth wrote:
> > I've verified that the shared library has it executable mode bits set.
> >
> > On 6/21/07, Jeff Johnson <***@gmail.com> wrote:
> > >
> > > On Jun 21, 2007, at 1:13 PM, Xavier Toth wrote:
> > >
> > > > I previously had a package in which rolled up a number of shared
> > > > libraries. Now I've placed one of the shared libraries in its own
> > > > package. So now the shared library package no longer provides I'll
> > > > call it libx.so and the new package does. Other installed packages
> > > > depend on the libx.so shared library. When I try and update the shared
> > > > library package it fails because of the dependency of other packages
> > > > on the shared library that it previously provided. Also if I try and
> > > > install the new package it fails because of the conflict with the
> > > > shared library package over the providing of libx.so. What is the
> > > > correct way to handle such a situation? I'd prefer not to resort to
> > > > --force or --replacefiles.
> > > >
> > >
> > > You likely have forgotten the executable bit on the refactored libx.so
> > > library. Otherwise, you need a DT_SONAME in the library.
> > >
> > > rpm tries very hard to never automagically extract dependency info for
> > > non-executables.
> > >
> > > hth
> > >
> > > 73 de Jeff
> > >
> > > _______________________________________________
> > > Rpm-list mailing list
> > > Rpm-***@redhat.com
> > > https://www.redhat.com/mailman/listinfo/rpm-list
> > >
> >
> > _______________________________________________
> > Rpm-list mailing list
> > Rpm-***@redhat.com
> > https://www.redhat.com/mailman/listinfo/rpm-list
> --
>
> Hiren Patel | Ops Specialist | ISS Infrastructure | Telkom
> E-Mail: ***@telkom.co.za Office: [phone] | Fax: [phone]
> 3299 | Cell: [phone]
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> This e-mail and its contents are subject to the Telkom SA Limited
> e-mail legal notice available at
> http://www.telkom.co.za/TelkomEMailLegalNotice.PDF
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-***@redhat.com
> https://www.redhat.com/mailman/listinfo/rpm-list
>

[Xavier Toth]

That's an interesting idea I'll check it out, thanks.

On 6/26/07, Peter Smith <***@utsouthwestern.edu> wrote:
> Have you given any thought to using the "Obsoletes" tag? I wonder if this is the solution to the problem? Or, have you already come up with one? I was looking carefully at a page that has *some* info which includes it [1].
>
> Peter
>
> [1] http://annvix.org/Documentation/Dev/Building/Specs
>
> >>> "Xavier Toth" <***@gmail.com> 06/23/07 9:27 AM >>>
> I agree that this will work but I was hoping for a solution that
> wouldn't require this drastic of measures. In my case I've got 80
> other packages that are affected and the idea of having to uninstall
> and reinstall all of them is not nice to put it mildly.
>
> On 6/22/07, Hiren Patel <***@telkom
> > try finding out what packages depend on libx.so, remove those packages,
> > upgrade the package containing the shared libs, install the package
> > contain the one isolated lib, and then install the packages you removed
> > that depended on libx.so
> >
> > On Thu, 2007-06-21 at 12:54 -0500, Xavier Toth wrote:
> > > I've verified that the shared library has it executable mode bits set.
> > >
> > > On 6/21/07, Jeff Johnson <***@gmail.com> wrote:
> > > >
> > > > On Jun 21, 2007, at 1:13 PM, Xavier Toth wrote:
> > > >
> > > > > I previously had a package in which rolled up a number of shared
> > > > > libraries. Now I've placed one of the shared libraries in its own
> > > > > package. So now the shared library package no longer provides I'll
> > > > > call it libx.so and the new package does. Other installed packages
> > > > > depend on the libx.so shared library. When I try and update the shared
> > > > > library package it fails because of the dependency of other packages
> > > > > on the shared library that it previously provided. Also if I try and
> > > > > install the new package it fails because of the conflict with the
> > > > > shared library package over the providing of libx.so. What is the
> > > > > correct way to handle such a situation? I'd prefer not to resort to
> > > > > --force or --replacefiles.
> > > > >
> > > >
> > > > You likely have forgotten the executable bit on the refactored libx.so
> > > > library. Otherwise, you need a DT_SONAME in the library.
> > > >
> > > > rpm tries very hard to never automagically extract dependency info for
> > > > non-executables.
> > > >
> > > > hth
> > > >
> > > > 73 de Jeff
> > > >
> > > > _______________________________________________
> > > > Rpm-list mailing list
> > > > Rpm-***@redhat.com
> > > > https://www.redhat.com/mailman/listinfo/rpm-list
> > > >
> > >
> > > _______________________________________________
> > > Rpm-list mailing list
> > > Rpm-***@redhat.com
> > > https://www.redhat.com/mailman/listinfo/rpm-list
> > --
> >
> > Hiren Patel | Ops Specialist | ISS Infrastructure | Telkom
> > E-Mail: ***@telkom.co.za Office: [phone] | Fax: [phone]
> > 3299 | Cell: [phone]
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > This e-mail and its contents are subject to the Telkom SA Limited
> > e-mail legal notice available at
> > http://www.telkom.co.za/TelkomEMailLegalNotice.PDF
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > _______________________________________________
> > Rpm-list mailing list
> > Rpm-***@redhat.com
> > https://www.redhat.com/mailman/listinfo/rpm-list
> >
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-***@redhat.com
> https://www.redhat.com/mailman/listinfo/rpm-list
>
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-***@redhat.com
> https://www.redhat.com/mailman/listinfo/rpm-list
>