[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

        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.

 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: