jcfranks at tpg.com.au
Sun Jan 23 00:52:27 CET 2005
Brian J. Tarricone wrote:
> hi all,
> i have an idea... not sure if it's worth the work, but i thought i'd
> put it out there. in light of all the problems with people upgrading,
> and trying to use parallel stable and CVS, do we perhaps want to start
> versioning the filenames of our libs a bit better?
> ideally, we'd be doing something like "libxfcegui-4.3.so",
> "libxfceutil-4.3.so", etc. etc. note that i took the "4" out of the
> library names altogether, which i guess might be a bit lame to do at
> this point, so we'd stick with the lameness of "libxfcegui4-4.3.so"
> and "libxfce4util-4.3.so", etc. or perhaps, since we're versioning
> the .pc files as, e.g., "libxfcegui4-1.0.pc", we could just increment
> the minor on that guy, and use that in the filename versioning as
> well. so we'd have, for the current CVS, libxfcegui4-1.3.pc and
> libxfcegui4-1.3.so. or something like that.
It really should be libxfcegui-4.3.pc, not libxfcegui4-1.3.pc. Why have
an extra version number (1.3) tacked on the end.
> 1) no more complaints about "undefined: xfce_builtin_license_GPL" and
> the like.
> 2) no more complaints from people wanting to install both in parallel
> (presumably, to different prefixes: i'm not advocating putting minor
> version suffixes on the binaries too).
> 3) easier for us devs to have 4.2 and stable on our machines for
> patching and bugfixing and testing and whatnot.
> 1) we have to figure out the naming scheme. if we want to do it the
> totally aesthetic way (libxfceutil-4.3), then that involves actually
> changing the package name, which would probably be more trouble than
> it's worth. so we could just do libxfce4util-4.3, or libxfce4util-1.3
> (i prefer -4.3). looks a little confusing, but who cares, really?
Wasn't this one of the issues raised by Benedikt, rationalizing the
names and number of CVS modules?
> 2) plugins would now be required to update their dependencies when we
> do a new 4.x release, since (presumably) the normal user would want to
> uninstall their old libraries when they upgrade, and since the soname
> is different, they'll have dangling library deps. for 4.2, all we
> required was a recompile, which the user can do on their own. but
> updating the required library soname requires configure.ac hacking
> (ok, it's only a one-line change per library, but still). to be the
> most flexible, this would require something lame-looking like:
> BM_DEPEND_CHECK([LIBXFCE4UTIL], [libxfce4util-4.3], [4.2.0])
> if test "x$LIBXFCE4UTIL_FOUND" != "xyes"; then
> BM_DEPEND([LIBXFCE4UTIL], [libxfce4util-1.0], [4.2.0])
> so, thoughts? i'd be willing to make the required
> makefile/configure.ac/pkgconfig changes necessary for all modules,
> though 3rd-party plugin authors would have to make the changes
It would be worth making these changes, so that the problem gets fixed,
once and for all.
Just my thoughts,
More information about the Xfce4-dev