From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: Package API compatibility and guix package variable names Date: Wed, 27 Jul 2016 23:06:15 +0200 Message-ID: <20160727230615.33d2adc3@scratchpost.org> References: <20160719205719.20769-1-rekado@elephly.net> <87y44wdr1f.fsf@elephly.net> <20160727175431.35fc6326@scratchpost.org> <20160727161918.GA5300@solar> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSW29-0006Lk-Cf for guix-devel@gnu.org; Wed, 27 Jul 2016 17:06:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSW23-0003bM-88 for guix-devel@gnu.org; Wed, 27 Jul 2016 17:06:28 -0400 Received: from dd1012.kasserver.com ([85.13.128.8]:43077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSW23-0003al-0t for guix-devel@gnu.org; Wed, 27 Jul 2016 17:06:23 -0400 In-Reply-To: <20160727161918.GA5300@solar> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Andreas Enge Cc: guix-devel Hi Andreas, On Wed, 27 Jul 2016 18:19:18 +0200 Andreas Enge wrote: >It is our common practice to not re-encode the version into the name: Usually the unnumbered name simply stands for the latest version That's unfortunate. I can live with it - but there is a reason the API major versions are usually encoded there. Otherwise it's not possible to ever make a clean API break and be safe with it. Just to make sure: I'm not saying the API major number should absolutely be part of the name, I'm saying there should be version bounds for all the inputs of packages. > In this way, updating dependencies becomes easier: Most of the time, a later version of a dependency will work. Then there would have been no reason to update the API major number in the first place. Of course I can think of scenarios where it would work regardless - for example if the package used only a subset of the entire functionality, it could be that this subset is still compatible. Python 3 is an example - few Python 2 programs will work on Python 3 without changes - so it makes no sense to "autoupdate" a Python 2 package to a Python 3 interpreter in isolation. Of course, if you are lucky, you can find some subset where it happens to work by accident. When Python 4 is released, a similar argument can be made. >To follow your suggestion, we would ultimately add the soname of libraries to package names, Only the part that is the API (in)compatibility version number - but yes. > and then whenever some package is updated, all packages depending on it would need to have > their inputs rewritten. Hopefully after checking whether the new API actually still does the right thing for it... Thanks, good to know the common practice.