On Sun, Jun 04, 2006 at 03:44:03PM -0500, Joe Wreschnig wrote:
> On Sun, 2006-06-04 at 20:56 +0200, Raphael Hertzog wrote:
> > now you know a bit better the policy (or at least the generic idea, feel
> > free to discuss details further),
> No. After the previous thread I am still in the dark on:
On Mon, Jun 05, 2006 at 12:24:19AM +0200, Marc Dequènes wrote:
> >> 3) The tight upper bound on module dependencies will be removed,
> >> provided the module actually works on future versions of Python. The
> >> upper bound on extension dependencies will not, because then they
> >> wouldn't work.
On Sun, Jun 04, 2006 at 11:44:00PM +0200, Matthias Klose wrote:
> > 4) python2.x-* virtual packages are to be used only when necessary, but
> > packages can provide them regardless.
> you don't know in advance, if they are necessary. Not a problem, if
> they are generated.
No, but they can be add
Em Dom, 2006-06-04 às 20:56 +0200, Raphael Hertzog escreveu:
> I agree with Matthias that it would be better to use only one "helper
> tool" but I would favor python-support instead of python-central for the
> reasons outlined below. Beware this is only *my* opinion. I'll gladly
> follow the consen
On Sun, Jun 04, 2006 at 07:16:14PM +0200, Marc Dequènes wrote:
> >> Let me reexplain the situation i was talking about with a little graph:
> >> python-editobj (using python-support)
> >>|
> >> python2.3-soya (compiled)
> >>|
> >> python-ontopofsoya (using python-support)
> >
Coin,
Matthias Klose <[EMAIL PROTECTED]> writes:
> s/available/supported/. we will try to keep the number of supported
> python versions/implementations minimal.
Is there difference between available and supported versions ? What use
for an official python package if it is not supported ?
> Pl
Joe Wreschnig writes:
> 1) Public modules and extensions should support all available Python
> versions, using a single binary package.
s/available/supported/. we will try to keep the number of supported
python versions/implementations minimal.
> 2) A new control field, XC-Python-Version will be
On Sun, 2006-06-04 at 23:05 +0200, Raphael Hertzog wrote:
> On Sun, 04 Jun 2006, Joe Wreschnig wrote:
> > On Sun, 2006-06-04 at 20:56 +0200, Raphael Hertzog wrote:
> > > Hello,
> > >
> > > now you know a bit better the policy (or at least the generic idea, feel
> > > free to discuss details furthe
Joe Wreschnig writes:
> On Sun, 2006-06-04 at 20:56 +0200, Raphael Hertzog wrote:
> > Hello,
> >
> > now you know a bit better the policy (or at least the generic idea, feel
> > free to discuss details further),
>
> No. After the previous thread I am still in the dark on:
> - Tight upper depende
Hi,
On Sun, 04 Jun 2006, Joe Wreschnig wrote:
> On Sun, 2006-06-04 at 20:56 +0200, Raphael Hertzog wrote:
> > Hello,
> >
> > now you know a bit better the policy (or at least the generic idea, feel
> > free to discuss details further),
>
> No. After the previous thread I am still in the dark on:
On Sun, 2006-06-04 at 20:56 +0200, Raphael Hertzog wrote:
> Hello,
>
> now you know a bit better the policy (or at least the generic idea, feel
> free to discuss details further),
No. After the previous thread I am still in the dark on:
- Tight upper dependencies. We you just incorrect, or are t
Hello,
now you know a bit better the policy (or at least the generic idea, feel
free to discuss details further), it's time to think about the
implementation (for modules and extensions).
References used:
- python-support source package in Debian
- python-central source package on http://people.d
Coin,
Steve Langasek <[EMAIL PROTECTED]> writes:
>> Let me reexplain the situation i was talking about with a little graph:
>
>> python-editobj (using python-support)
>>|
>> python2.3-soya (compiled)
>>|
>> python-ontopofsoya (using python-support)
>>|
>> slune
On Fri, 02 Jun 2006, Joe Wreschnig wrote:
[Steve Langasek]
> > Yes, this was also discussed in the BoF, with the same conclusion: because
> > providing python2.x-foo can only be done safely if the package depends on
> > the python2.x versions of all other modules it requires, making transitions
> >
14 matches
Mail list logo
