Naming standalone module/program
Hi, I'm just finishing my new plucker package. And then I read the policy again, and it said I should call my program python2.1-plucker, as I use method 2 and the upstream name is plucker. But this is not a module intended to be used by others, only by the programs that comes with plucker. So I'd like to call it just plucker, and make shure there is just one (working) version in debian. Is this OK? /Micce -- Mikael Hedin, MSc +46 (0)980 79176 Swedish Institute of Space Physics +46 (0)8 344979 (home) Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile) [gpg key fingerprint = 387F A8DB DC2A 50E3 FE26 30C4 5793 29D3 C01B 2A22]
Re: Experimental Python packages
Neil Schemenauer [EMAIL PROTECTED] writes: python_2.1.1 python1.5_1.5.2 zope2.3.3 Why not python-1.5_1.5.2, zope-2.3.3 and similar binary packages? I think this namenumber scheme is ugly and it looks strange. name-version is more clear IMO. These create the following binary packages: python-base python-dev python-elisp Why not python instead of python? I want to be able to apt-get install python and dpkg -p python. Then python could confilct with python-base, and in that way force all old module packages that depend on python-base to get updated to their new version that depend on python (= 1.5), python (1.6). /Micce -- Mikael Hedin, MSc +46 (0)980 79176 Swedish Institute of Space Physics +46 (0)8 344979 (home) Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile) [gpg key fingerprint = 387F A8DB DC2A 50E3 FE26 30C4 5793 29D3 C01B 2A22]
Re: Question for the transition
So file bug on the packages in question. They could also depend on python(=1.5), python(1.6). See my other postings on this. /Micce -- Mikael Hedin, MSc +46 (0)980 79176 Swedish Institute of Space Physics +46 (0)8 344979 (home) Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile) [gpg key fingerprint = 387F A8DB DC2A 50E3 FE26 30C4 5793 29D3 C01B 2A22]
Proposal for transition--FRD
Hi, from the thread I started, I propose we try this: 1) Every package that depend on python checks if it works with python 2.1. 2) We upload python-base v. 2.1, and most of the packages will have to make a new upload (depend on python-base (=2.1 2.2) if anything installed in .../python2.1/). 3) If any package fail 1), we create python1.5-base, and that package will be built accordingly. 4) Everyone be happy with the clean package namespace. 5) This propably mean all packages that depend on python-base (1.6) -- which shoud be any with files in .../python1.5/ -- will have to go into testing at the same time. Will this cause a problem? 6) All packages with files in .../python1.5/ without versioned depends get a critical bug. 7) Contemplate the posibility to install modules in /usr/lib/python-modules/, i.e. a version independent place. (I remember the python people have some objection, but forgot which.) 8) Flame me for writing long task lists. /Micce -- Mikael Hedin, MSc +46 (0)980 79176 Swedish Institute of Space Physics +46 (0)8 344979 (home) Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile) [gpg key fingerprint = 387F A8DB DC2A 50E3 FE26 30C4 5793 29D3 C01B 2A22]
Re: Proposal for transition--FRD
Carey Evans [EMAIL PROTECTED] writes: Mikael Hedin [EMAIL PROTECTED] writes: [...] 6) All packages with files in .../python1.5/ without versioned depends get a critical bug. Unfortunately, this leaves someone's system broken if they just install some Python packages, and leave the packages that currently depend on python-base ( 1.5.2) installed. The best solution to this is to get rid of python-base, and have all packages depend on python-base-x.y or similar. Packages only get into Why not the exciting name python? And confilcts with python-base? Then all the module that depend on python-base (xxx) to be either upgrader or removed. Am I right? It's really strange that we have no python package now, try 'dpkg -p python'. /Micce -- Mikael Hedin, MSc +46 (0)980 79176 Swedish Institute of Space Physics +46 (0)8 344979 (home) Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile) [gpg key fingerprint = 387F A8DB DC2A 50E3 FE26 30C4 5793 29D3 C01B 2A22]
Question for the transition
Hi, I'm probably missing something big, but here are my thoughts: Why mess with all these versioned python? Could we not have python-base (that will be version 2.1 soon), and for the ones who need, python-base-x.y? And the python-base will be the default/newest available? If packages install modules in .../python1.5/xxx, they have to depend on python (=1.5, 1.6). Any package that violates this has a serious bug, and it can be easily fixed. Packages could preferably install modules in /usr/lib/python/xxx, and the no versioned depend is needed. The python-base then has to compile all the modules in /usr/lib/python/ on an upgrade. This seems too simple, what am I missing? I think the proposed scheme with python2.1 and module2.0 et.al. is really ugly and messy. As a luser, I would be confused with all these numbers in the names of packages. There should be only python, python-this and python-that too choose from. In my opinion that is. Please enlighten me! (I maintain plucker, a small pyton package.) /Micce -- Mikael Hedin, MSc +46 (0)980 79176 Swedish Institute of Space Physics +46 (0)8 344979 (home) Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile) [gpg key fingerprint = 387F A8DB DC2A 50E3 FE26 30C4 5793 29D3 C01B 2A22]
Re: Python 2.0.1; transition plans for woody
Please go ahead! The fewer nameX type packages the better. Should be no problems for plucker (=me) /Micce -- Mikael Hedin, MSc +46 (0)980 79176 Swedish Institute of Space Physics +46 (0)8 344979 (home) Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile) [gpg key fingerprint = 387F A8DB DC2A 50E3 FE26 30C4 5793 29D3 C01B 2A22]
