Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#118916: wajig: should depend on python, not python-base

0 views
Skip to first unread message

Dirk Eddelbuettel

unread,
Nov 10, 2001, 9:23:54 PM11/10/01
to

"Ben" == Ben Burton <be...@acm.org> writes:
Ben> Package: wajig Version: N/A; reported 2001-11-09 Severity: serious
Ben>
Ben> Hi. Package wajig cannot be installed because it depends on the
Ben> non-existant "python-base". Python packages have recently been
Ben> changed according to the new python policy. Wajig should depend on
Ben> "python" instead.

Yes, I goofed. The only lame excuse is that it worked on my testing box.

Now, as I read the python-policy.txt, I should Depends / Build-Depends as in

Source: wajig
[...]
Build-Depends: debhelper (>> 3.0.0), python2.1-dev
[...]
Package: wajig
Depends: python (>= 2.1), python (<< 2.2), wget, apt

However wajig is a "mere" Python app, and a package providing modules. I have
verified that my 1.5.2 build works with /usr/bin/python2.1 -- so could I
not use

Source: wajig
[...]
Build-Depends: debhelper (>> 3.0.0), python-dev
[...]
Package: wajig
Depends: python, wget, apt

instead? Please advise as I am unable to make up my mind here. Python Policy
seems clear enough, but overly restrictive for this case.

My current changelog draft is:

wajig (0.2.8-2) unstable; urgency=low

* Adapted Python Policy (as of version 0.3.7)
* debian/control: Depends python (>= 2.1), python (<< 2.2) (Closes: #118916)
* debian/control: Added Build-Depends on python2.1-dev (Closes: #19009)

-- Dirk Eddelbuettel <e...@debian.org> Sat, 10 Nov 2001 20:18:38 -0600


Thanks, Dirk

--
Better to have an approximate answer to the right question
than a precise answer to the wrong question. -- John Tukey


--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Matthias Klose

unread,
Nov 11, 2001, 5:48:22 AM11/11/01
to
Dirk Eddelbuettel writes:
>
> "Ben" == Ben Burton <be...@acm.org> writes:
> Ben> Package: wajig Version: N/A; reported 2001-11-09 Severity: serious
> Ben>
> Ben> Hi. Package wajig cannot be installed because it depends on the
> Ben> non-existant "python-base". Python packages have recently been
> Ben> changed according to the new python policy. Wajig should depend on
> Ben> "python" instead.
>
> Yes, I goofed. The only lame excuse is that it worked on my testing box.
>
> Now, as I read the python-policy.txt, I should Depends / Build-Depends as in
>
> Source: wajig
> [...]
> Build-Depends: debhelper (>> 3.0.0), python2.1-dev
> [...]
> Package: wajig
> Depends: python (>= 2.1), python (<< 2.2), wget, apt
>
> However wajig is a "mere" Python app, and a package providing modules. I have
> verified that my 1.5.2 build works with /usr/bin/python2.1 -- so could I
> not use

No. It depends on a specific version of python, as it includes the
.py[co] files, which are version specific. The package works with any
Python version >= 1.5, but if the version for generating the compiled
files and the version for running the compiled files are different,
then the compiled files aren't used. And running wajig as root, writes
new compiled files ...

> Source: wajig
> [...]
> Build-Depends: debhelper (>> 3.0.0), python-dev
> [...]
> Package: wajig
> Depends: python, wget, apt
>
> instead? Please advise as I am unable to make up my mind here. Python Policy
> seems clear enough, but overly restrictive for this case.

yes, we may want to have something like a python-register-files, which
is called in the postinst/prerm, which compiles these files for the
current version, but nobody yet volunteered ...

What you already can do is to call py_compile in the postinst. See the
/usr/doc/python2.1/sample.p* files for an example.

> My current changelog draft is:
>
> wajig (0.2.8-2) unstable; urgency=low
>
> * Adapted Python Policy (as of version 0.3.7)
> * debian/control: Depends python (>= 2.1), python (<< 2.2) (Closes: #118916)
> * debian/control: Added Build-Depends on python2.1-dev (Closes: #19009)
>
> -- Dirk Eddelbuettel <e...@debian.org> Sat, 10 Nov 2001 20:18:38 -0600

I didn't look at the new source, but build-depending on python2.1-dev
means that you have to call python2.1 during the build. `python' may
point to something else, if we change the python version to 2.2. So
either build-depend on python (>= 2.1), python (<< 2.2) or use
`python2.1'.

Matthias

Dirk Eddelbuettel

unread,
Nov 11, 2001, 7:46:15 AM11/11/01
to

"Matthias" == Matthias Klose <do...@cs.tu-berlin.de> writes:
>> * Adapted Python Policy (as of version 0.3.7) * debian/control: Depends
>> python (>= 2.1), python (<< 2.2) (Closes: #118916) * debian/control:
>> Added Build-Depends on python2.1-dev (Closes: #19009)
>>
>> -- Dirk Eddelbuettel <e...@debian.org> Sat, 10 Nov 2001 20:18:38 -0600
Matthias> I didn't look at the new source, but build-depending on
Matthias> python2.1-dev means that you have to call python2.1 during the
Matthias> build. `python' may point to something else, if we change the
Matthias> python version to 2.2. So either build-depend on python (>= 2.1),
Matthias> python (<< 2.2) or use `python2.1'.

I still don't get it. What is the difference? python2.1 vs python2.1?
Further, Python Policy states

You should not make a default, unversioned module package
`python-<foo>' depend on the versioned Python package `python<X>.<Y>'!

The source package must declare

Build-Depends: pythonX.Y-dev

where <X>.<Y> is the version used in the `Depends'.

so python2.1 would be out of the picture as per the first cited paragraph.

Can you enlighten me?

Dirk


--
Better to have an approximate answer to the right question
than a precise answer to the wrong question. -- John Tukey

Anthony Towns

unread,
Nov 11, 2001, 8:02:45 AM11/11/01
to
On Sun, Nov 11, 2001 at 06:40:22AM -0600, Dirk Eddelbuettel wrote:
> Matthias> So either build-depend on python (>= 2.1),

> Matthias> python (<< 2.2) or use `python2.1'.
> I still don't get it. What is the difference? python2.1 vs python2.1?

"python (>= 2.1)" ensures /usr/bin/python is python version 2.1 or above.
"python (<< 2.2)" ensures /usr/bin/python is python version 2.1 or below
"python2.1" ensures /usr/bin/python2.1 is python version 2.1.

These are all different statements as far as how you'll write your
scripts and such.

> Further, Python Policy states
> You should not make a default, unversioned module package
> `python-<foo>' depend on the versioned Python package `python<X>.<Y>'!

Conside what would happen if you wrote a script that began:

#!/usr/bin/python
import foo

and put it in a package "bar" and depended on "python,
python-foo". Someone might then go along and install python2.1_*.deb,
python_2.1.1-4.deb, and python-foo_*.deb, and have everything work
happily. Then some months later they might want to install python 2.2,
at which point they could have:

python_2.2.3-1.deb
python2.1_2.1.1-4.deb
python2.2_2.2.3-1.deb
python-foo.deb
bar.deb

all installed. But since python-foo provided python version 2.1 modules
(and depends upon python2.1), the script will no longer work since
/usr/bin/python is now python version 2.2.

Cheers,
aj

--
Anthony Towns <a...@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

"Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it.
C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who
can't deal with deconstructionist humor. Code Blue."
-- Mike Hoye,
see http://azure.humbug.org.au/~aj/armadillos.txt

0 new messages