kage.
>
> The difference: on $RANDOM_UNIX_SYSTEM you don't know that pythonX.Y
> is in /usr/bin, but on a debian system you do and on a debian system
> you'd rather not deal with other installations in $ENV.
i think we pretty much all agree here. what about changing the python
policy?
particularly good/obvious package to start from?
checkinstall is pretty good for personal use, but the debs produced
are not suitable for inclusion in the project, imho.
--
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
Those who do not stu
Il mer, 2002-11-27 alle 11:11, Luca - De Whiskey's - De Vitis ha
scritto:
> * configuring: each product will restart Zope while configuring.
> * end: Zope will restart only once at the end of the whole
> installation/upgrading process.
> * manually: You will have to restart Zope.
>
Il mer, 2002-11-27 alle 09:53, Andreas Tille ha scritto:
> On Wed, 27 Nov 2002, Luca - De Whiskey's - De Vitis wrote:
>
> > Sure, that's the way (by now) the shared template works. debconf-devel(7)
> > says:
> >
> > SHARED TEMPLATES
> >It's actually possible to have a template and a questi
lation/upgrading process.
> * manually: You will have to restart Zope.
> * product: each product will ask you how to proceed.
are you sure we need the same qustion in every package? package's
installation scripts can just ask the debconf database and pull user's
preferences (
x27;re using the python2.2-gtk package you should do something like:
import pygtk
pygtk.require('2.0')
from gtk import *
...
--
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
INIT.D Developer
*default* python if not yet
installed. so what about the versioned main package and then the valid
alternatives? mm..
--
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
INIT.D Developer [EM
h to 2.2 now and then again
> to 2.3. But anyway, let's make unstable really unstable first by
> switching to gcc-3.2 as the default compiler (coming soon :-)
eheh. given that sarge won't be stable for another 12 months
(optimistically) 2.3 will have plenty of time to stabilize.
y do once we have 2.2 by default. I need
> 2.2 for python2.2-dictclient, and for boost_python v2. (I've already got
> a "local install" of newer pygame and pyopengl).
python 2.2 is stable. do we have any important modules that *don't* work
with 2.2? if not we can make
scans
the region for sequences of spaces, and converts sequences of at least
three spaces to tabs if that can be done without changing indentation.
`M-x untabify' changes all tabs in the region to appropriate numbers of
spaces.
--
Federico Di Greg
package *depends* on a real package, should i
include the copyright even in the dummy package, symlink the doc
directory or file an override to lintian?
--
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
INIT.D Devel
ith debian sonames. shouldn't a package name libfoo4 provide
a library named libfoo.so.4.x.x? so, the right name is
libsip-python2.1.so.2.0.0
or
libsip2-python2.1.so
or
libsip.so.2.python2.1.x.y... ugly! it is even possible?
--
Federico Di Gregorio
Debian GNU/Li
t python versions require different libsi, then libsi *must*
have a different soname and you can install both at the same time (as
per debian library policy.)
am i missing something?
federico
--
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact
5: xracer 0.96.9-10 xracer-tools 0.96.9-10 all
are those the only packages still depending on 1.5 or there are others?
would be nice to remove python 1.5 (really old, now) for woody.
ciao,
federico
--
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTEC
ackages are now in incoming.
thank you very much joel!
--
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
INIT.D Developer [EMAIL PROTECTED]
Qu'est ce que la folie? Juste un sentiment de libe
n avoid such bloat.
agreed again. list all the packages that need to be ported to 2.1 and
lets start working. only after *all* packages get ported we can remove
python1.5 and all dependents packages.
ready to help,
federico
--
Federico Di Gregorio
Debian GNU/Linux Dev
debian is b0rken.
sic.
> Postscript: fog, does that mean that you intend to continue to maintain
> python1.5-psycopg for a while?
at least until python1.5 exits from debian.
--
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
INIT.D
ng has versions with the following
dependencies:
python-psycopg: python2.1-psycopg, python (>= 2.1), python (<< 2.2)
python2.1-psycopg: python2.1-egenix-mxdatetime, python2.1
python1.5-psycopg: python-egenix-mxdatetime, python1.5
zope-psycopgda: zope, python2.1-psycopg
works for me.
f
On Wed, 2001-11-14 at 14:45, Tille, Andreas wrote:
> On Wed, 14 Nov 2001, Federico Di Gregorio wrote:
>
> > three copies? seems we have one copy of the same binary under three
> > names here. unix support hardlinks, remember?
> But are this *really* hardlinks?
look at the
blem which is the main target of my
> question) before I file a bug report.
three copies? seems we have one copy of the same binary under three
names here. unix support hardlinks, remember?
--
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTEC
.1-egenix-mxdatetime and works perfectly. the old mx packages
without 'egenix' in the name are deprecated and should be avoided. (i
think they will be removed from the archive upon no other packages
depending on them.)
ciao,
federico
--
Federico Di Gregorio
Debian GNU/Linux Developer
On Sun, 2001-10-28 at 22:55, Joel Rosdahl wrote:
> Federico Di Gregorio <[EMAIL PROTECTED]> writes:
> > i plan to drop support for 1.5 from psycopg (at least in debian
> > builds) when we'll have a zope for python 2.1 in the archive.
>
> Okay. Will this happen
On Sun, 2001-10-28 at 22:34, Joel Rosdahl wrote:
> Hi,
>
> I have now finished Debianizing eGenix mx BASE (based on patch done by
> Federico Di Gregorio, see bug#56):
>
> http://www.lemburg.com/files/python/eGenix-mx-Extensions.html
>
> The upstream mainta
>
> However, xml tools for python would stay python-xml.
terrible. while changing all packages to use libXXX-python is aceptable,
the best thing is to stick to python-XXX. a lot of people expect it this
way and is at least coherent.
--
Federico Di Gregorio
MIXAD LIVE Chief of Research &
stable systems are there to be broken. if a lot of people
outside debian development use unstable on production machine, that is
their fault. (well, partly. even with testing debian is way too slow to
release, imho.)
ciao,
federico
--
Federico Di Gregorio
MIXAD LIVE Chief of Research & Te
ning ;-)
ciao,
federico
--
Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology [EMAIL PROTECTED]
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
God is real. Unless declared integer. -- Anonymous FORTRAN programmer
26 matches
Mail list logo
