Re: gtkmm2.4 is obsolete: documentation for this, and 10.7 ?

Max Horn <[email protected]> Fri, 30 Sep 2011 16:52:22 +0200
Newsgroups gmane.os.apple.fink.gnome
Message-ID <[email protected]>
Hi Daniel, all!

Thanks for your reply and explanations, much appreciated!


Am 28.09.2011 um 16:46 schrieb Daniel Macks:

> On Wed, 28 Sep 2011 12:27:33 +0200, Max Horn  wrote:
>> 
>> today I was trying to build a package using gtkmm2.4 (specifically,
>> the package "surfer"), and since I was using "-m --build-as-nobody"
>> as is my habit, Fink error out like this:
>> 
>> WARNING: The package surfer has a preferred BuildDepends on gtkmm2.4-dev,
>>  but gtkmm2.4-dev is an obsolete package.
>> 
>> 
>> I was confused at first, because there is no outward sign that
>> gtkmm2.4-dev is obsolete. Indeed, "fink info gtkmm2.4-dev" says
>> nothing about this!
> 
> 'fink info' has included this information for several years now:
> 
> $ fink info gtkmm2.4-dev
> 
> gtkmm2.4-dev-2.18.2-1: C++ interface for the gtk+2 library
>  .
>  Web site: http://www.gtk.org
>  .
>  Maintainer: The Gnome Core Team <[email protected]>
>  .
>  Note: This package is obsolete. Maintainers should upgrade their
>  package dependencies to use its replacement, which is probably:
>  gtkmm2.4-gtk-dev (>= 2.18.2-1), pangomm1.4.1 (>= 2.14.0-1)
> 
> That "Note" is automatically generated from the Depends field.

True, I forgot that -- sorry, my fault :(.

But lazy guys like me just look at "fink list gtkmm2.4" and don't see nothing. While lazy guys like me do deserve some pain, I think it will still be beneficial if we do everything we can to get even those to do the right thing ... and in this case it seems like low-hanging fruit :). 

> 
>> it should be made crystal clear for packagers that they are doing
>> something wrong, and how to do it right.
> 
>> 
>> Hence, could at the very least the "Description:" fields for gtkmm2.4
>> and gtkmm2.4-dev be changed to contain "OBSOLETE" and a hint as to
>> what the migration plan is ?
> 
> Adding the OBSOLETE token to the Description is fine, along with a
> package-name when it's a 1:1 droping replacement. And indeed
> 
> $ fink fink list glibmm2.4
> 
>      glibmm2.4        2.22.2-2     OBSOLETE: use package
> 'glibmm2.4-dev' ins...
> 
> as well as the Note in the 'fink info'.

Indeed. And just for completeness and the record, here the contrasting bad case of gtkmm2.4:

$ fink list gtkmm2.4
Scanning package description files..........
Information about 10429 packages read in 2 seconds.
 i   gtkmm2.4               2.18.2-1         C++ interface for the gtk+2 library
     gtkmm2.4-dev           2.18.2-1         C++ interface for the gtk+2 library
 i   gtkmm2.4-gtk-dev       2.18.2-1         C++ interface for the gtk+2 library
 i   gtkmm2.4-shlibs        2.18.2-1         C++ interface for the gtk+2 library


> However, many of the
> replacements are not 1:1 so having this as the way to display them
> doesn't seem as useful.

Not sure what "this as the way" refers to -- maybe to having the migration instruction included in "Description" ? If so, yeah, sure, that won't work in general. All I am hoping for is a Description string saying something like
  OBSOLETE: See 'fink info' for migration instructions


> The replacement for qt4-x11-core-shlibs is 10
> packages with fairly long names and specific minimum-versions, so
> better to *at least* have "OBSOLETE" in the Description and then the
> place the data is always included automatically is in the 'fink info'
> more detailed output.

Seems to me we agree :).

[...]

> I ripped out the obsolete packages from a bunch of package-sets in 10.7
> a few weeks ago, and there is therefore no such package as "glibmm2.4"
> there at all (just its -shlibs and -dev components).

Great :)

> Looks like I got
> distracted before finishing gtkmm2.4...will work on it this week.
> Definitely worth pinging the maintainers of others to fix theirs for
> the 10.7 clean-slate world. If anything in 10.7 still has a dependency
> on them, this is also a perfect time to ugprade there (and also
> backport to 10.[56] so everyone gets better). On the other hand...
> 
>> My guess is that we can also do this for the 10.5/10.6 packages,
>> though, there shouldn't be serious migration troubles, right?
> 
> That's a recipe for all sorts of deadlocks. One of the simplest
> patterns is a .info that contains foo, foo-dev, and foo-shlibs, with
> the following dependcies:

Right, I kind of was hoping it wouldn't be a problem anymore, because gtkmm2.4 has been obsolete for so long...  but of course it is, because things still depend on it! And hence the problems you list and explain *do* turn up. Bad idea... Buuuut:

[...]

>  The only way it
> would generally work is if there were a separate RuntimeDepends field
> (like Depends, but *not* also enforced as a BuildDepends).

Yeah, the mythical RuntimeDepends... I've been dreaming about that for a loooong time ... ;) Anyway, I decided it has been far too long, so here is an implementation. Still with some rough edges, but working:

  <https://github.com/fingolfin/fink/commits/feature/runtimedeps>
  <https://github.com/fingolfin/fink/compare/master...feature%2Fruntimedeps>

While doing this, I discovered various other oddities, quirks and stuff. I'll discuss this patch as well as my other findings on fink-core :)


Cheers,
Max
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
fink-gnome-core mailing list
[email protected]
List archive:
http://news.gmane.org/gmane.os.apple.fink.gnome
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-gnome-core