Max,
As to technical discussions, please review the
proposed refactoring of gcc4x...
-------------------------------------------------
One small additional comment, sorry ..
Going for such a structure, it helps a lot
(to speed up upgrading by users and other
pkgs) if the main pkg (the symlinks) is
called plainly say "gcc", w/o any versioning.
(Indeed, then a "selfupdate" makes them
automatically update their gcc pkg _
further, the name is free in fink's namespace,
so take it!)
To keep coexisting info files, it means then
that those have to be named eg as
gcc4x-compiler.info
and have the "gcc" pkg as a splitoff.
(cf eg already gettext-bin for an example).
In general such a refactoring may be a
big hassle, and require substantial
reworking of the info file, but in this
case you are lucky :
- all the work is done in "gcc4x-compiler"
- then a Splitoff gets you as now "gcc4x-shlibs"
- then in Spitoff2 (this is "gcc") you create
(in its InstallScript) all the symlinks to %N
Sorry _ but much better to think of such things
before rather than too late..
Best,
JF
-------------------------------------------------
How exactly does this fit into fink policy? More
importantly, how can you even install a particular
version of the the gcc split-off if they all share
the same package name. It is obvious to most users
that gcc44 gets you gcc-4.4.x. What does gcc get
you (4.3? 4.4? 4.5?). You should put all your packaging
up for full review and see how fun it is until
everyone agrees with it. Oh, sorry I forgot...
# DISCLAIMER: Max Horn is the sole maintainer of this package.
# Please DO NOT MAKE MODIFICATIONS without informing the maintainer.
# Preferably, send a patch to me instead of making changes yourself!
# If that is not possible due to extra urgency, at least send me a mail.
#
# Explanation: I am sick and tired of getting back to my packages and
# discovering that people have messed with it. I am then forced to
# retrace their steps, find out who, when and why did make a certain
# change etc. -- i.e. it makes my life as maintainer harder.
# Furthermore, as maintainer I am responsible for problems caused by my
# packages. But I am not willing to take responsibility for something I
# did not do. In particular, for changes that other people introduced
# behind my back, no matter how good and noble their intentions were. As
# such, I may see myself forced to drop responsibility for (and hence,
# maintainership of) the affected package.
...you exempted yourself from that process.
Jack
------------------------------------------------------------------------------
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
