On Fri, 2006-06-09 at 08:32 +0200, Raphael Hertzog wrote:
> On Mon, 05 Jun 2006, Raphael Hertzog wrote:
> > On Sun, 04 Jun 2006, Joe Wreschnig wrote:
> > > policy is. So here's *my* attempt at summarizing the BoF, based on your
> > > first mail and responses, and independent of the tools used:
> >
On Mon, 05 Jun 2006, Raphael Hertzog wrote:
> On Sun, 04 Jun 2006, Joe Wreschnig wrote:
> > policy is. So here's *my* attempt at summarizing the BoF, based on your
> > first mail and responses, and independent of the tools used:
> >
> > 1) Public modules and extensions should support all available
Le dimanche 04 juin 2006 à 20:56 +0200, Raphael Hertzog a écrit :
> Josselin can you provide a dh_python following those rules? Would anyone
> else be ready to write it? (I could do it, I told so to doko but in fact
> my only interest here is to solve the current problems and not to stay
> heavily
On Tue, 06 Jun 2006, Matthias Klose wrote:
> > > > What for? Modules are automatically available to all python versions
> > > > (except those which do not support all versions, but then we can't do
> > > > better...).
> > >
> > > please read again. I'm not talking about shared modules.
> >
> > I'
Raphael Hertzog writes:
> On Tue, 06 Jun 2006, Matthias Klose wrote:
> > > > The 'Provides: python2.3-foo, python2.4-foo' is missing for all
> > > > packages with private modules and scripts (without shared modules).
> > > > For that case we do need XB-Python-Version. If we do want to drop the
> >
On Tue, 06 Jun 2006, Matthias Klose wrote:
> > > The 'Provides: python2.3-foo, python2.4-foo' is missing for all
> > > packages with private modules and scripts (without shared modules).
> > > For that case we do need XB-Python-Version. If we do want to drop the
> > > Provides for packages where t
On Tue, 2006-06-06 at 10:31 +0200, Raphael Hertzog wrote:
> > no, not for packages with private extensions.
>
> Does this kind of package exist? (ie do you have an example?)
fonttools does.
--
bye,
pabs
http://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed me
Raphael Hertzog writes:
> On Tue, 06 Jun 2006, Matthias Klose wrote:
> > assume we want to add a python2.5 package. It's nice to have, but
> > extensions will need an update, or they will FTBFS. At this point I
> > would rather not see python2.5 as supported.
>
> Agreed, however it would be nice f
On Tue, 06 Jun 2006, Matthias Klose wrote:
> assume we want to add a python2.5 package. It's nice to have, but
> extensions will need an update, or they will FTBFS. At this point I
> would rather not see python2.5 as supported.
Agreed, however it would be nice for package which do already work wit
> > 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 ?
assume we want to add a python2.5 package. It'
Joe Wreschnig <[EMAIL PROTECTED]> writes:
> CDBS is not necessary; look at python-gst0.10's packaging. The versions
> it's built for is controlled entirely via a single Make variable, and it
> uses regular debhelper. This could be further refined to find all
> installed versions of Python at build
Steve Langasek <[EMAIL PROTECTED]> writes:
> - An Arch: any python-foo extension package must depend on
> python (>= $minver), python (<< $maxver+1), where $minver is the earliest
> python ABI that it includes a compiled extension for and $maxver is the
> latest python ABI that it includes a
On Mon, 2006-06-05 at 14:23 +0200, Marc Dequènes wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
>
> > No. An extension has to be separately *compiled* for each python version
> > it's to support. A python-foo package containing
> > /usr/lib/python2.3/site-packages/foo/foo.so and
> > /usr/li
On Mon, Jun 05, 2006 at 02:23:45PM +0200, Marc Dequènes wrote:
> So, that's my idea, willing to automatize all complicated build rules,
> and remove the upper boundaries in dependencies, which would be rendered
> useless by intelligent binNMUs.
Er, I guess you do understand since you agreed with
Of course, i'd be glad to help concretly. I'm not a Python expert, but i
could help on the CDBS front, and test solutions (like i did with Joss
for python-support recently), and provide some valuable documentation
(even if the CDBS documentation forked, i'm still updating the original
version regu
Steve Langasek <[EMAIL PROTECTED]> writes:
> No. An extension has to be separately *compiled* for each python version
> it's to support. A python-foo package containing
> /usr/lib/python2.3/site-packages/foo/foo.so and
> /usr/lib/python2.4/site-packages/foo/foo.so must not claim to be compatible
On Sun, 04 Jun 2006, Joe Wreschnig wrote:
> policy is. So here's *my* attempt at summarizing the BoF, based on your
> first mail and responses, and independent of the tools used:
>
> 1) Public modules and extensions should support all available Python
> versions, using a single binary package.
>
On Sun, 04 Jun 2006, Matthias Klose wrote:
> > - python2.x-* packages -- are they needed? desirable?
> >Steve and Matthias gave different answers, and if they're present
> >migrations end up just as fragile as they are now.
>
> No, not different answers. They may be needed, if an extensio
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
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
28 matches
Mail list logo
