Re: dh_python and python policy analysis
On Sun, 13 Aug 2006 10:28:43 -0700, Steve Langasek <vorlon@debian.org> said:
> On Sun, Aug 13, 2006 at 03:32:27AM -0500, Manoj Srivastava wrote:
>> On Sun, 13 Aug 2006 00:01:37 -0700, Steve Langasek
>> <vorlon@debian.org> said:
>> > On Sat, Aug 12, 2006 at 12:10:07PM -0500, Manoj Srivastava wrote:
>> >> >> 3.1.3. Provides
>> >> >> Packages with public modules and extensions should be named,
>> >> >> or should provide, python-foo. Pure Python public modules
>> >> >> that support all Python versions need not have a Provides
>> >> >> field.
>> >> > ... unless there is an application using a non-default python
>> >> > version using this module. or else you require the application
>> >> > depending on any indirect dependency of python-foo.
>> >> Hmm. Two things: if application X requires my pure python
>> >> public module (called, say, python-foo), and uses some specific
>> >> version of python, why can't it depend on just python-foo Why do
>> >> I have to provide pythonX.Y-foo?
>> > Because a dependency on "python-foo" expresses the request "give
>> > me the foo module for the current version of python".
>> No, it does not. When a package bar depend on package baz, it means
>> just that-- that it requires the package baz to work. With the
>> policy draft that I have proposed, if it is a pure python module,
>> with no intrinsic restrictions on the versions of python supported,
>> other packages can just depend on the package, knowing that a
>> policy compliant package would support all available versions.
> Then what do you name a package that is a pure python module that
> *DOES* have intrinsic restrictions on the version of python
> supported?
WShy do you need a special name? Had you read the actual
proposed draft, you'd realize that we do cater to that possibility.
> You are wrong to assume that a pure python module will automatically
> support all available versions of python -- if all python versions
> were completely backwards- and forwards-compatible with one another,
> there would be no reason in the first place to *have* multiple
> versions of them in the archive.
> The reality is that there *are* language differences with each
> implementation of python, and a pure python module may *not* work
> with any given implementation of python available in the archive,
> and we need a way to express such dependencies that guards users
> against package relationships being satisfied by broken
> combinations.
In these two paragraphs you are doing three things.
a) Belabouring the obvious
b) jumping to conclusions about what I assume,
c) demonstrating that you have not read the proposed draft.
>> > There is no guarantee that the python-foo package installed is
>> > compatible with, or provides support for, the pythonX.Y you're
>> > using, except if this package declares a Provides: pythonX.Y-foo;
>> > so the depends/provides:
>> Rubissh. You are just making up these rules, and since it hurts,
>> just don't make them up.
> What hurts is your ignorance of design requirements that were
> discussed at length at the DebConf python BoF.
A little knowledge is dangerous. Go and educate yourself on
what is being discussed in this thread -- or, if you are too
almighty busy to familiarize yourself with the things you weigh in
on, let meattempt to summarize, eliding any "oooh shiny" sections:
If you are packaging a public pure python module (not
extension or private modules), there are two cases: either you have
intrinsic versions dependencies in your module, or not.
If you have version dependencies, your Depends and Provides
rules are differennt, and you need to read the draft to see what they
are.
If there are no such internal dependencies, then you need not
provide pythonX.Y-foo virtual packages, since you should arrange for
your packages to be compiled for any new version that is uploaded.
As to the BOF thing, I'll bite: Why one earth did the bof come
up with design decisiosn that require every single goldarned python
module package to be reuploaded every time a new version of python is
added or removed?
Why did the BOF choose to ignore the experience of the emacs
listp community, that also has byte compilation issues, and subtle
differences in byte compiler? Were the people in the bof aware that
the python interpreter, like emacs itself, can optionally byte
compile source on the fly, and lal that is lost is some speed?
Frankly, if the BOF came up with a design that requires every
single public pure python module to be uploaded every single time a
new version of python is added or removed, than you should be happy I
am ignoring their delibrations.
Byte compiling interpred language files is not rocvket
science. It is also not a new problem.
manoj
beginning to realize why the state pof python in Debian is such a mess
--
To err is human, to moo bovine.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: