On Sat, 14 Jul 2001, D-Man wrote:
> On Sat, Jul 14, 2001 at 04:05:56PM +1200, Carey Evans wrote:
> | D-Man <[EMAIL PROTECTED]> writes:
> |
> | > Yes. Maybe each extension should just depend on a single version of
> | > python and need to be rebuilt for each new python release.
> |
> | It makes things considerably simpler, from my point of view.
> |
> | Then, of course, we need unique package names for each package.
>
> Yeah
>
> | Something like "python-imaging-python1.5", "python-imaging-python2.0"
> | and "python-imaging-2.1"? Aagh.
>
> Since we have "python1.5" and "python2.1", how about
> "python1.5-imaging" and "python2.1-imaging". Then if the maintainer
> wants to include a version on the package it could be (I don't know
> PIL's version) "python2.1-imaging2.3". I don't think that is too
> ugly.
I like:
package gets you
------- ---------
python the default|recommended|required
Python for the Debian release
python-<version> whatever you would get if you build from
the official source release
python-<version>-<package> a subset of "python-<version>", or an
extension that depends on <version>
python-<package> a subset of "python", or
version-neutral extension
task-python-<label> convenience packages, just depends
Of course, which packages would be real and which are virtual (etc.)
will take additional figuring. e.g.,
sum(python-<version>-{subsets}) = python --> python-<version>
or = python-<version> --> python
...
or is that too simple and I missed some common situation?
- Bruce
p.s. - I prefer python-<version> over python<version> because it is
prettier to look and more consistent (->prettier code too) --
compare...
basename[-<label>]... vs. basename[<version>][-<label>]...
and consider coding to parse a package name or generate one from
pieces... <version> is a special case.
