On Wed, 5 Apr 2017 13:11:56 +0200, Vít Ondruch wrote: > Is this some special process for js-jquery? No. > It is quite common that package bumps its version or soname and breaks > something. We either fix the incompatibility or provide "compat" package. > > You can take recent update of openssl from 1.0.1 to 1.1.0 as an example. > It was updated just to later introduce compat-openssl10 to not break the > systems that much. A bad example, if that has happened to stable dist releases. Hopefully it has been specific to Rawhide. That upgrade involves a SONAME change, which results in different _automatic_ strict RPM dependencies on the SONAME, possibly with symbol versioning even. It's impossible to install that package, if any installed package requires the old lib. It's dependency breakage that ought to be avoided. Try releasing the same faulty upgrade to stable dists and have fun dealing with package conflicts, if not replacing/renaming the packages properly. Don't do that to your distribution's users, please. > How many libpng versions we have currently in Fedora and yet I don't see > any Obsoletes/Provides in any of them. You mean those ancient packages? Some even from Red Hat Linux! Some of the later ones have had Obsoletes in them temporarily, but it is common practice to remove Obsoletes tags after some dist releases. The %changelog mentions that sometimes. > I keep js-jquery requires strictly versioned especially to know that > js-jquery version was changed so I can fix my package appropriately. Fine, but as I've pointed out, then the upgrade would break such dependencies already and might break the runtime of packages that don't work with API changes anymore and have only specified a weak dep, such as a non-versioned one or one using '>='. > > Hence something would need to "Provides: js-jquery = 2.something", so no > > deps would break. > > Dependency breakage is not anything exeptional we don't deal with. Avoiding dependency breakage as often as possible is the thing that makes one package collection better than another. Confronting users with dependency problems (such as uninstallable updates and unresolvable deps) is bad. > I say that releasing js-jquery2 package is just "nice to have" and I > have use case for it. But world will not break apart if js-jquery2 is > not introduced. As I understand it, the plan is to introduce it, but as a replacement of the current js-jquery package before upgrading that one to v3. > > Temporarily the new package would also > > duplicate files found in another package or conflict with it even, > > if it doesn't _replace_ the other package. > > Yes, and to avoid them, the proposal is to regularly bump js-jquery to > version 3.x and deal with the outfall (very likely by introducing > js-jquery2). Bad idea. The replacing/renaming procedure is cleaner than breaking installations and trying to fix the mess afterwards. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
