Philip Brown wrote:
it would appear as though there is a metric boatload of packages that
acutally use libnet. (I'm rather surprised at some of them...
No shit, I was also surprised how many packages actually was using
libnet, but I think there are some other lib which they use, which was
linked against libnet.
"gpdf" ??? What's up with that??
and gedit??
I've rebuild gedit 1.14.4 and I can't see any reason why libnet should
be needed. It must have been some dependant library that used libnet in
the past.
Regarding gpdf, that package should be scrapped since we have evince
which is gnome's replacement.
normally, i would suggest forcing dependant packages to be recompiled, to
match release of a new package.
But there's just too many to do that in this case.
Wow, these libnet people are incompetant.
If the versions are incompatible, it should be a major REV bump!!!
sheesh.
Well, first of all, they don't create a shared library, all
distributions which have that, have done that by themself. Their normal
installation just creates a static library.
Secondly regarding version numbers, it all depends on how you look at
it, there are many different ways how people use version numbers.
If they have had release shared libraries a major rev bump would be
required, but since they don't version number is just a version number
of their software. There are several software packages where the library
version number doesn't match the software version number.
Sadly.... I dont see much choice in what we can do.
We cant just break 30 packages... but at the same time, we need to be
able to recompile things against the newer stuff!
in a clean, sane manner that doesnt require ludicrous backflips for
maintainers.
Well, what we could do is first re-release 1.0.2 with SONAME set, then
re-release all dependant packages, then release 1.1.2 so any package
which support or require 1.1.x can be released.
I know that this might be a undesirable way, but maybe the "cleanest".
_______________________________________________
maintainers mailing list
[email protected]
https://lists.opencsw.org/mailman/listinfo/maintainers
