Dne 5.4.2017 v 13:45 Michael Schwendt napsal(a): > 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. Just to make sure, I'll quote myself from my initial response: Dne 4.4.2017 v 08:05 Vít Ondruch napsal(a): > Please do these changes just in Rawhide. > >> 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. Certainly not the case for libpng15: http://pkgs.fedoraproject.org/cgit/rpms/libpng15.git/log/ But you are right that there is one trace of "Provides: libpng.so.3" from 2003 in changelog. > >> 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 '>='. Hopefully we have test suites and Koschei to discover this breakages early. > >>> 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 agree and this whole thread is about plan to avoid them. I appreciate that Christopher reached to me individually as well as this ML to coordinate. > >> 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. Well, I think that the plan was for discussion and I think it needs some tweaks. From my POV it should be: 1) Update js-jquery to 3.x 2) Ensure as much packages as possible work with the updated package. 3) Introduce the js-jquery2 4) Enusre that the rest of jQuery 3.x incompatible packages are using js-jquery2. > >>> 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. This is always to consider. I think we should know what is actually the impact, so it is probably time to maintainers of following packages to speak up: $ dnf repoquery --whatrequires js-jquery Last metadata expiration check: 0:20:32 ago on Wed Apr 05 13:49:37 2017 CEST. beets-plugins-0:1.4.3-2.fc26.noarch jpype-doc-0:0.6.1-6.fc26.noarch js-jquery-datetimepicker-0:2.5.4-1.fc27.noarch js-jquery-file-upload-0:9.17.0-1.fc26.noarch js-jquery-iframe-transport-0:1.0.1-1.fc26.noarch js-jquery-jstree-0:3.3.3-1.fc26.noarch js-jquery-knob-0:1.2.13-2.fc26.noarch js-jquery-mousewheel-0:3.1.13-1.fc26.noarch js-jquery-noty-0:2.4.1-1.fc27.noarch js-php-date-formatter-0:1.3.4-1.fc26.noarch js-tag-it-0:2.0-1.fc26.noarch koschei-frontend-0:1.9.1-1.fc27.noarch mkdocs-0:0.16.1-3.fc26.noarch python-systemd-doc-0:234-1.fc27.x86_64 python-txaio-doc-0:2.5.2-2.fc26.noarch python2-sphinxcontrib-programoutput-0:0.8-10.fc27.noarch python3-sphinxcontrib-programoutput-0:0.8-10.fc27.noarch rubygem-jquery-rails-0:4.2.2-2.fc26.noarch I am speaking as maintainer of rubygem-jquery-rails and I'd love to see js-jquery updated to version 3.x and introduced js-jquery2, without any Obsoletes/Provides and I will work with Christopher to ensure that rubygem-jquery-rails keeps working. Vít _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
