https://bugzilla.redhat.com/show_bug.cgi?id=1194212 --- Comment #11 from T.C. Hollingsworth <tchollingsworth@xxxxxxxxx> --- (In reply to Michael Schwendt (Fedora Packager Sponsors Group) from comment #10) > Alternatively, it could store the .so symlink outside %_libdir (as to > prevent a conflict) and adjust the compiler/linker search via option -L. That would break binary compatibility for every nodejs binary addon module, particularly those end users install with npm. I really wanted to avoid breaking end-user installed modules without an obvious major version bump in nodejs, when end-users should expect it anyway. (Unless of course I add it to /etc/ld.so.conf.d/, but then the libuv.so in there might conflict with that of the regular libuv package.) > No. It used to be a tradition. Eventually, somebody breaks with the > tradition and "abuses" the naming scheme. If compat- is not appropriate for this package, it would be nice if there were an alternate prefix that still made it clear that this package is never to be used for building new software. While we still do need the headers to build nodejs, I didn't want to leave the impression that this package is useful for anything else, like simply naming it libuv010 would do. > > > RHEL>=5? > > RHEL5 is too old. It does not generate Requires for pkg-config > inter-dependencies either (i.e. RPM deps for the "Requires:" lines in the > .pc files!). > > https://fedoraproject.org/wiki/Packaging: > Guidelines#BuildRequires_based_on_pkg-config > > > > I didn't drop it because it's harmless and I wasn't sure which branch > > might still need it... > > Well, if this will be released even for EPEL5, you may want to properly > replace the old package: Well, the main libuv package (where many of the pkgconfig bugs you pointed out were copied from wholesale ;-) is present in EPEL5. But... > https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming. > 2FReplacing_Existing_Packages > > That's the only well-defined way to get rid of the old libuv package always. > Else it's implementation-dependent whether a depsolver would look for the > new libuv package even if nothing needed it yet. Also keep in mind that > plain "rpm" evaluates Obsoletes tags when installing/updating packages > manually. ...the Obsoletes situation would be the same everywhere, since I would only introduce this package into a branch where I would intend to update the libuv to 1.4.0 like I just did in Rawhide and F22. And AIUI I should not have this package obsolete libuv, since libuv has another dependent that is compatible with the new version. (moarvm, which I rebuilt earlier) Instead, users of the only package that needs this compat library (nodejs) will have to live with a useless libuv package for one release. (Until Fedora 23 where libuv can Obsolete this when it is no longer needed.) Regardless of whether or not I add Obsoletes, the upgrade path is preserved, since nodejs' requires on libuv.so.0.10()%{?_isa} will drag in compat-libuv010 now that libuv no longer provides it. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review