Date: Tue, 19 Mar 2019 14:08:24 +0100
From: u-3qpt@aetey.se
To: Natanael Copa <ncopa@alpinelinux.org>
Cc: Drew DeVault <sir@cmpwn.com>, alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Normalizing Python packages in aports
Message-ID: <20190319130824.GN23721@example.net>
References: <20190306212501.GD2800@cirno.localdomain>
 <20190314112413.29dd9816@ncopa-desktop.copa.dup.pw>
 <20190314191241.GF1544@homura.localdomain>
 <20190319103153.3964ded5@ncopa-desktop.copa.dup.pw>
 <20190319113230.GM23721@example.net>
 <20190319125738.73f31222@ncopa-desktop.copa.dup.pw>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190319125738.73f31222@ncopa-desktop.copa.dup.pw>

On Tue, Mar 19, 2019 at 12:57:38PM +0100, Natanael Copa wrote:
> On Tue, 19 Mar 2019 12:32:30 +0100
> u-3qpt@aetey.se wrote:
> > From this point of view, it is important to (also) name all python3
> > packages as py3-*.
> 
> always name all python3 packages py3-* would also make it possible to
> install py4-* and py3-* in parallel if for some reason that would be
> needed in future.

It is always useful to be able to do parallell installations,
this avoids artificial collisions when different packages need different
packages which want to occupy the same naming slot.

> python3.6 and python3.7 will not be possible to install in parallel.

Why not? As long as "python3" is the only one which is named "python3"
and, say, depends on a certain one of 3.6 or 3.7.

Then the semantics of "python3" and the corresponding contract
against other packages is clear: "only the features which are
present in 3.x for all x<=N". Then the consumer can either accept this
contract or explicitly refer to, say "python3.7" if it needs
a feature not present in the "pyhton3" contract.

Of course there will be still possibilities to choose wrong,
but at least the semantics can be specified unambiguously
and there will be no collisions.

Redundancy may appear if different consumers pull in both 3.6 and
3.7. But as well this can mean that really both 3.6 and 3.7 are needed
on the computer in question. No breakage in either case.

> > Please do not perpetuate the others' badly chosen practices - they can
> > not be made consistent other than only temporary and only with a large
> > effort each time, if at all.
> 
> what about `python-dev`? should you get latest python or failure?

If you ask me - this is clearly underspecified and _must_ fail.

How do I as a packager know which of the "python-family" languages the
local sysadmin will want his users to develop in?

"Latest" has no stable mapping, how can a consumer (another package or
a local administrator) rely on it without checking what "latest" means
in the context of "python-dev"? Somewhat later this may no longer be
the same? No, thanks.

Of course nothing prevents having a package "pythonLatest-dev" with a
description "this will correspond to yet unknown versions of "Python"
depending on the pace of the development of the language and on how fast
we will update the corresponding packages, updates will change what you
get via this package, possibly to something incompatible".

This might be exactly what someone needs for a day, but probably not what
someone else needs to specify dependencies in his python-related package.

Regards,
Rune



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---