Hi,

On 9/02/2013 23:15, Alexis Ballier wrote:
Dear fellow developers,

I hope this will be trivial to most of you but after seeing bug #455900
and the vast majority of developers not even thinking twice before
sedding their dep strings, I believe this needs some attention.

What is wrong with maintainers just updating their dependencies in this fashion? Surely the onus in this case is on package maintainers setting sensible subslots (which is indeed what you appear to be saying below)?

I even noticed some maintainers adding subslots dependencies on libraries that do not yet define subslots. This too seems reasonable, given that there would be no impact until the library defines a (sensible) subslot in the future.


What do subslots do: You set a subslot to a package and every time said
package subslot changes (e.g. with an update), others packages
depending on it with a := dep will be rebuilt. Nothing more, nothing
less.

Now, this solves a real problem: haskell, perl and ocaml packages need
to be rebuilt after updating their respective compiler/interpreter and,
in some cases, even after updating the libraries they use. Subslots
would make haskell-updater, perl-cleaner and ocaml-rebuild not needed
in the future.

You can also use subslots to notify an ABI change in a shared library,
in order to avoid having to use preserve-libs or run revdep-rebuild.
However, this week I had to rebuild webkit-gtk three or four times and
libreoffice twice...
If you want to notify ABI changes, then you should set subslot to
something representing the ABI, $PV as subslot is most certainly wrong
in that case. Subslot is *not* a substitute to checking your library
ABI, checking if its reverse dependencies work fine after the update,
and notifying upstream if something went wrong so they can make a quick
release fixing their mistake. Subslot is also *not* a substitute to
soname and ensuring ABI compatibility (at least forward) between
libraries with the same major. Using subslot only to be on the safe
side and forcing a rebuild of all the dependent packages because it is
too much work to check the ABI and work with upstream is, IMHO, a
serious QA issue.

Thank you for your attention,

Alexis.



Best regards,
Michael


Reply via email to