https://bugzilla.redhat.com/show_bug.cgi?id=1194212 --- Comment #12 from Michael Schwendt (Fedora Packager Sponsors Group) <bugs.michael@xxxxxxx> --- > That would break binary compatibility for every nodejs binary > addon module, ??? Currently, you don't ship any .so symlink at all in the package. I really only refer to the _symlink_, i.e. a libuv.so that is needed for -luv to work at buildtime. Adding such a file _somewhere_ would certainly not break anything. > (Unless of course I add it to /etc/ld.so.conf.d/, That directory is for runtime, not buildtime. > 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. People happily build with what they find. If you wanted to prevent that, don't ship a -devel package. Which is no solution, if you still want to (re)build existing packages. Hey, you could make it harder to build with this -devel package. ;-) > 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. The contents matter more than the name. Currently, it _is_ quite an ordinary parallel-installable library package. (There are no naming guidelines for those either, AFAIK). > ...the Obsoletes situation would be the same everywhere, Even more reason to add Obsoletes/Provides as explained in the guidelines. Imagine what a depsolver needs to do when it finds both the old libuv (providing the same SONAME Provides) and compat-libuv010 in the repo. Behaviour is not well-defined. Developers of package tools have argued quite a bit about what should happen, if e.g. the user runs "yum install something". Yum would take either one it finds, possibly still the shortest package name. > And AIUI I should not have this package obsolete libuv, That's why Obsoletes are versioned. You tell the depsolver that package B replaces package A of versions "less than" something, so the newer package A version is not obsoleted. That's also the way to avoid that the new libuv gets installed when it's not needed by anything. The current packaging only works out of coincidence, because a tool like Yum eventually notices the new libuv and uses it to replace the old libuv while installing compat-libuv010 to satisfy dependencies. Without Obsoletes, you strictly depend on such implementation behaviour, and you get the new libuv installed even if it will be unused. > 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. That's the less clean renaming. It's not the first time that an old package name continues to live on with an incompatible new version of the package software. For example: Qt 4 in "qt" renamed to "qt4" with Qt 5 in "qt". Yes, those packages contain Obsoletes. Not the only example, if one searches a bit. -- 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