On Thu, 8 Jul 2010, Marc Espie wrote:
On Thu, Jul 08, 2010 at 02:03:41PM +0200, Matthieu Herrb wrote:
On Thu, Jul 08, 2010 at 11:50:39AM +0200, Marc Espie wrote:
each time xenocara farts, we get new libs (or less libs).
in order for updates to work, we *should* propagate those changes to
@wantlib in each port.
For the base and xenocara libs, wouldn't it make sense to have some
modules centralizing the version info (and even some dependencicies) so
that instead of WANTLIB declaratons you coud have
.include <libX11.dep.mk>
.include <libc.dep.mk>
or something similar?
Then only one central fil would need to be updated when revisions changes.
And even if libX11 gains new depencies, you would not be reqired to
add the manually to a zillon of ports's Makefiles.
Nope, because it does not do half the work: bumping pkgnames.
Doing stuff automatically every time will mean you will get to update a lot
of packages.
Basically, if you have two packages with the same name, and differing WANTLIB,
how do you know which one is the newest ?
the one with the highest CVS revision ID attached?
The CVS revision number is guaranteed atomically increasing
and only relevant if it's used as a tie breaker against two
otherwise similar versions.
there's probably an obvious reason why this is a bad idea.
Sam
--
Talk does not cook rice
- Chinese Proverb
