On Wed, 6 Apr 2011 08:32:44 -0400, Charles Lepple wrote:
On Apr 6, 2011, at 7:19 AM, Max Horn wrote:
>
> > My view: I would prefer to follow the policy and rev up packages; if
> > a user still has them installed, this way they explicitly see that
> > they are about to update an obsolete package (something they may
> > have missed in the past due to a confusing description text). If
> > there are any truly big packages with an obsolete splitoff, we could
> > either make an exception for that, or just wait with releasing the
> > desc fix until there is a natural update coming anyway.
>
> I like the general idea, FWIW. It's something that will help make it a
> little more obvious which package to install when searching the PDB.
> (Ideally, IMHO, it would be nice to have the PDB or even "fink list"
> be able to hide obsolete packages unless a flag is set, but that can
> be done down the road.)
>
> Along those lines, if it looks like a package needs to depend on fink-
> obsolete-packages, I'm putting my vote in for adding that dependency
> when you modify the description. (Although I see AKH just posted a
> good argument for not doing that if the obsolete package doesn't have
> its own info file.)
"obsolete" has the technical meaning of "has dependency on f-o-p". This
is just about adding an obvious Description for these technically
obsolete packages. There are lots of other packages that have newer
alternatives, but may require various changes to switch to them, so the
old ones are not as definitely "no reason to be using this old thing".
So if a package got renamed or diffused into another package, the old
name would be an obsolete one because there is no reason to continue to
use it. The old package is just a dummy pointing to the new one. But if
there is an old library-version (libgettext3-{dev,shlibs} vs
libgettext8-{dev,shlibs}), the old one is still a real separate set of
files and completely appropriate to use in certain cases due to binary
linking and such.
> I've been thinking about separating the splitoff for geda-* into its
> own bundle package (now that upstream has been distributing a single
> tarball for everything), and this is as good a time as any for me to
> do that (taking a few packages off of your list). If I don't get to it
> soon, though, feel free to handle that however you see fit.
Let me know if you want me to test when you (or someone else) has
something cobbled together for this. I know lots of tricks related to
OBSOLETE, but I don't know enough about the layout (and its changes) to
feel comfortable diving in without guidance.
dan
--
Daniel Macks
dma...@netspace.org
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
