glib[2] issue

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

glib[2] issue

Alexander Hall
Hi!

While upgrading to the latest snapshot, i get a few messages like these:

----8<---- Snipped from long list of stuff ----8<----
Can't install atk-1.10.3p0: lib not found glib-2.0.600.4
Even by looking in the dependency tree:
         expat-1.95.6, libiconv-1.9.2p1, glib2-2.8.3, gettext-0.14.5
Maybe it's in a dependent package, but not tagged with @lib ?
(check with pkg_info -K -L)
If you are still running 3.6 packages, update them.
-----------------------------------------------------

And (part of) ``pkg_info -K -L expat-1.95.6 libiconv-1.9.2p1 glib2-2.8.3
gettext-0.14.5'' reads:

----8<---- Long list again ----8<----
Information for glib2-2.8.3

Files:
@file /usr/local/bin/glib-genmarshal
@file /usr/local/bin/glib-gettextize
@file /usr/local/bin/glib-mkenums
@file /usr/local/bin/gobject-query
@file /usr/local/include/glib-2.0/glib-object.h
@file /usr/local/include/glib-2.0/glib.h
@file /usr/local/include/glib-2.0/glib/galloca.h
@file /usr/local/include/glib-2.0/glib/garray.h
@file /usr/local/include/glib-2.0/glib/gasyncqueue.h
@file /usr/local/include/glib-2.0/glib/gatomic.h
@file /usr/local/include/glib-2.0/glib/gbacktrace.h
@file /usr/local/include/glib-2.0/glib/gcache.h
@file /usr/local/include/glib-2.0/glib/gcompletion.h
-------------------------------------

So I say to myself: Aha! They _were_ in fact ``in a dependent package,
but not tagged with @lib'', as suggested.

I am not fully skilled in port/package handling, but If my assumption
above is correct, what is the proper procedure in these cases? Should I
notify the maintainer of glib2 so that these libs gets correctly tagged,
or could there be other reasons these kind of things does not work?

( Entire listings are preserved, should they be needed. )

/Alexander

Reply | Threaded
Open this post in threaded view
|

Re: glib[2] issue

Alexander Hall
Possibly correcting myself here...

Alexander Hall wrote:

> ...
> And (part of) ``pkg_info -K -L expat-1.95.6 libiconv-1.9.2p1 glib2-2.8.3
> gettext-0.14.5'' reads:
>
> ----8<---- Long list again ----8<----
> Information for glib2-2.8.3
> ...
> @file /usr/local/include/glib-2.0/glib/gcache.h
> @file /usr/local/include/glib-2.0/glib/gcompletion.h
> -------------------------------------

...but continues later on:
----------------------------------------------------------
@file /usr/local/share/locale/yi/LC_MESSAGES/glib20.mo
@file /usr/local/share/locale/zh_CN/LC_MESSAGES/glib20.mo
@file /usr/local/share/locale/zh_TW/LC_MESSAGES/glib20.mo
@lib /usr/local/lib/libglib-2.0.so.800.3
@lib /usr/local/lib/libgmodule-2.0.so.800.3
@lib /usr/local/lib/libgobject-2.0.so.800.3
----------------------------------------------------------

> So I say to myself: Aha! They _were_ in fact ``in a dependent package,
> but not tagged with @lib'', as suggested.

Well, no, it seems not. So I do not really get this. Please pick up your
finest clue-by-four and get it on. I could make guesses, but then again,
I could just hope for an educated (and educating!) answer instead.

/Alexander

Reply | Threaded
Open this post in threaded view
|

Re: glib[2] issue

Marc Matteo
In reply to this post by Alexander Hall
On Sun, 20 Nov 2005, Alexander Hall wrote:

> While upgrading to the latest snapshot, i get a few messages like these:
>
> ----8<---- Snipped from long list of stuff ----8<----
> Can't install atk-1.10.3p0: lib not found glib-2.0.600.4
> Even by looking in the dependency tree:
>        expat-1.95.6, libiconv-1.9.2p1, glib2-2.8.3, gettext-0.14.5

The atk you are updating was built against glib-2.0.600.4 and is not
seeing the glib-2.0.800.3 lib that the new package has (presumably) due to
the major lib bump.

devel/atk will need to be rebuilt.

This makes sense, but it leads to a question for me for the port masters:
In this case, atk will work with the newer lib version, so is there a way
to mark the port to allow this?

Or did I just screw up atk? :).

> I am not fully skilled in port/package handling, but If my assumption above
> is correct, what is the proper procedure in these cases? Should I notify the
> maintainer of glib2

Protocol is to notify the maintainer, wait a suitable amount of time and
then come here.

Marc

Reply | Threaded
Open this post in threaded view
|

Re: glib[2] issue

Alexander Hall
Marc Matteo wrote:
> This makes sense, but it leads to a question for me for the port
> masters: In this case, atk will work with the newer lib version, so is
> there a way to mark the port to allow this?

1. pkg_add -u complained about the following (updating all packages):
   glib-2.0.600.4
   gmodule-2.0.600.4
   gobject-2.0.600.4
   pango-1.0.800.1
   pangoft2-1.0.800.1
   t1.5.0

2. I had these corresponding libs installed:
   lib/libglib-2.0.so.800.3
   lib/libgmodule-2.0.so.800.3
   lib/libgobject-2.0.so.800.3
   lib/libpango-1.0.so.1001.0
   lib/libpangoft2-1.0.so.1001.0
   lib/libt1.so.6.0

3. library-specs(7) says:
     The package system will embed correct dependency checks in the
     built package, according to the normal shared library semantics:
     any library with the same major number, and a greater or equal
     minor number will do.

Thus, as far as I can see, all of these should have been identified. The
common denominator of these is the separation of the major, minor and
the rest of the numbers. And that there are so many of them, too. :-)

> Or did I just screw up atk? :).

I guess not, from the looks of it.

/Alexander

Reply | Threaded
Open this post in threaded view
|

Re: glib[2] issue

steven mestdagh
On Sun, Nov 20, 2005 at 10:09:58AM +0100, Alexander Hall wrote:

> Marc Matteo wrote:
> >This makes sense, but it leads to a question for me for the port
> >masters: In this case, atk will work with the newer lib version, so is
> >there a way to mark the port to allow this?
>
> 1. pkg_add -u complained about the following (updating all packages):
>   glib-2.0.600.4
>   gmodule-2.0.600.4
>   gobject-2.0.600.4
>   pango-1.0.800.1
>   pangoft2-1.0.800.1
>   t1.5.0
>
> 2. I had these corresponding libs installed:
>   lib/libglib-2.0.so.800.3
>   lib/libgmodule-2.0.so.800.3
>   lib/libgobject-2.0.so.800.3
>   lib/libpango-1.0.so.1001.0
>   lib/libpangoft2-1.0.so.1001.0
>   lib/libt1.so.6.0
>
> 3. library-specs(7) says:
>     The package system will embed correct dependency checks in the
>     built package, according to the normal shared library semantics:
>     any library with the same major number, and a greater or equal
                           ^^^^^^^^^^^^^^^^^
>     minor number will do.
>
> Thus, as far as I can see, all of these should have been identified.

no, the major number is not the same (800 vs 600).

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Reply | Threaded
Open this post in threaded view
|

Re: glib[2] issue

Alexander Hall
steven mestdagh wrote:

> On Sun, Nov 20, 2005 at 10:09:58AM +0100, Alexander Hall wrote:
>
>>Marc Matteo wrote:
>>
>>>This makes sense, but it leads to a question for me for the port
>>>masters: In this case, atk will work with the newer lib version, so is
>>>there a way to mark the port to allow this?
>>
>>1. pkg_add -u complained about the following (updating all packages):
>>  glib-2.0.600.4
>>  gmodule-2.0.600.4
>>  gobject-2.0.600.4
>>  pango-1.0.800.1
>>  pangoft2-1.0.800.1
>>  t1.5.0
>>
>>2. I had these corresponding libs installed:
>>  lib/libglib-2.0.so.800.3
>>  lib/libgmodule-2.0.so.800.3
>>  lib/libgobject-2.0.so.800.3
>>  lib/libpango-1.0.so.1001.0
>>  lib/libpangoft2-1.0.so.1001.0
>>  lib/libt1.so.6.0
>>
>>3. library-specs(7) says:
>>    The package system will embed correct dependency checks in the
>>    built package, according to the normal shared library semantics:
>>    any library with the same major number, and a greater or equal
>
>                            ^^^^^^^^^^^^^^^^^
>
>>    minor number will do.
>>
>>Thus, as far as I can see, all of these should have been identified.
>
> no, the major number is not the same (800 vs 600).

Ok, that makes sense. I mistakenly thought of the first available number
as the major number, and so on, as in

   glib-2.0.600.4
        ^ ^ ^^^^^
        | | +-> WFT?
        | +-> minor
        +-> major

Now I know better. Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: glib[2] issue

steven mestdagh
On Sun, Nov 20, 2005 at 10:31:43AM +0100, Alexander Hall wrote:

> steven mestdagh wrote:
> >On Sun, Nov 20, 2005 at 10:09:58AM +0100, Alexander Hall wrote:
> >
> >>Marc Matteo wrote:
> >>
> >>>This makes sense, but it leads to a question for me for the port
> >>>masters: In this case, atk will work with the newer lib version, so is
> >>>there a way to mark the port to allow this?
> >>
> >>1. pkg_add -u complained about the following (updating all packages):
> >> glib-2.0.600.4
> >> gmodule-2.0.600.4
> >> gobject-2.0.600.4
> >> pango-1.0.800.1
> >> pangoft2-1.0.800.1
> >> t1.5.0
> >>
> >>2. I had these corresponding libs installed:
> >> lib/libglib-2.0.so.800.3
> >> lib/libgmodule-2.0.so.800.3
> >> lib/libgobject-2.0.so.800.3
> >> lib/libpango-1.0.so.1001.0
> >> lib/libpangoft2-1.0.so.1001.0
> >> lib/libt1.so.6.0
> >>
> >>3. library-specs(7) says:
> >>   The package system will embed correct dependency checks in the
> >>   built package, according to the normal shared library semantics:
> >>   any library with the same major number, and a greater or equal
> >
> >                           ^^^^^^^^^^^^^^^^^
> >
> >>   minor number will do.
> >>
> >>Thus, as far as I can see, all of these should have been identified.
> >
> >no, the major number is not the same (800 vs 600).
>
> Ok, that makes sense. I mistakenly thought of the first available number
> as the major number, and so on, as in
>
>   glib-2.0.600.4
>        ^ ^ ^^^^^
>        | | +-> WFT?
>        | +-> minor
>        +-> major

No, some libraries have a release number within their library name, 2.0 in
this case. major.minor is the part after .so. You were probably confused
by the library spec which is an abbreviated form and leaves out the .so.
Look at the library filename to be sure.

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm