Re: Questions about packaging

[Danny Milosavljevic <dannym@scratchpost.org>]

[-- Attachment #1: Type: text/plain, Size: 2846 bytes --]

Hi,

On Fri, 11 Oct 2019 09:42:00 +0200
Tanguy Le Carrour <tanguy@bioneland.org> wrote:

> Le 10/10, Danny Milosavljevic a écrit :
> > > 1) Updating a package
> > > So I would have to update python-cachecontrol from 0.11.6 to 0.12.5.
> > > Should I create a python-cachecontrol-0.11.6 and fix all the packages
> > > that depend on it? Only the one that would break?  
> > 
> > The latter.  That's one of the things we do at Guix but I would not do at work.  
> 
> OK. I'll do that!
> My next question would be "when would someone create a versionned package name?"

If it's unavoidable.  One of the reasons is that we don't want to increase our
maintenance and testing burden unduly and thus would not want 453 versions of
the same package available at the same time (chances are that some combination
would not have been tested and/or not work).

But there are professional engineering standards which allow you to specify 
which versions of thing A can go with which other versions of thing B.

The most well-known type of that in software is semantic versioning.

So it depends on what kind of versioning scheme the project/package in question
uses.  If it does use semantic versioning or similar then packages which have
changes making it fundamentally incompatible with what came before will increase
their major version, basically making that an independent package (Debian for
example has the major version in that sense in their package NAMES for
libraries).

For example Python 3 is a new major version that is fundamentally incompatible
with Python 2 (cannot use the former as a drop-in replacement for the latter).

Therefore, there are packages for both Python 2 and Python 3, and for
many Python extensions, packages for a Python 2 and a Python 3 variant each. 

Eventually in some years, there will be no users (other packages) of Python 2
anymore.  Once that comes to pass we can drop Python 2.  What we can't do is
replace Python 2 by Python 3 in those user packages--it would break them.

It is necessary that such a versioning "judgement" mechanism be in place
for a package if you ever want to change your package in a backward-incompatible
manner if it has any users.

For a funny example where they didn't use such a mechanism, one HTTP header
entry is called "Referer", including the typo, for all eternity.  (it just
wasn't worth changing it--the knock-on-effect would have been enormous)

> Like for instance `openjdk`?

Openjdk (icedtea) is bootstrapped using the preceding major version of
each version.  icedtea-8 is built by icedtea-7, which is built by
icedtea-6, which is built by jamvm and GNU classpath, and so on, until
we end up at a C compiler interpreted by GNU Mes.  In this way we don't
have binary blobs anywhere but in GNU Mes at the bottom of it.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]