Migrating a package from from python-central: cleaning up (was: Piotrek's new preferred helper tool - (unfair) decision)
Piotr Ożarowski writes:
> PS while converting [from use of ‘python-central’ to use of
> ‘python-support’], remember to add to preinst something like these 3
> lines:
>
> | if [ "$1" = upgrade ] && dpkg --compare-versions "$2" lt 1.2.3-4; then
> | pycentral pkgremove python-foo
> | fi
As noted elsewhere, this is to overcome behaviour (discussed in
http://bugs.debian.org/479852>) that is the default for
‘dh_pycentral’: “create symlinks on postinst, don't clean up on
prerm”. Because it is the default, this likely plagues a significant
portion of ‘python-central’-based packages already installed out
there.
The approaches suggested in the ‘dh_pycentral(1)’ manpage are:
This can be disabled by setting the environment varibale
DH_PYCENTRAL to a string containing the string noprepare. If the
newer version of a package needs to remove the symlinked files on
upgrade, either the package needs to take care of the removal by
calling pycentrel pkgremove in the new preinst, or leaving a file
/var/lib/pycentral/.pkgremove and using pycentral 0.6.7
or later for the old package version.
I, like Piotr, am now preparing to migrate my Python packages to use
‘python-support’ (once the new version that stops using ‘/var/lib/’
hits ‘testing’). What is my best approach for preparing to do this? As
I see it, the existing documentation suggests one of:
* Leave the package for now depending on ‘python-central’, set
‘DH_PYCENTRAL = noprepare’ in my existing packages's
‘debian/rules’, then build and upload a new release; or
* Migrate the package immediately to use ‘python-support’, put the
call to ‘pycentral pkgremove foopackage’ in ‘preinst’ as shown
above by Piotr, then build and upload a new release; or
* Migrate the package immediately to use ‘python-support’, create an
empty ‘${DESTDIR}/var/lib/pycentral/foopackage.pkgremove’, then
build and upload a new release; or
* Something else (please specify).
Which of the above is best in general? What reasons would I have for
not doing the same thing to every affected package? How long should I
leave these measures in place before removing all mention of
‘python-central’ from a new release?
--
\ “When I get new information, I change my position. What, sir, |
`\ do you do with new information?” —John Maynard Keynes |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: python-nxt
Sebastian Reichel wrote: > On Tue, Mar 03, 2009 at 06:20:33PM +0100, Emilio Pozuelo Monfort wrote: >> Really? Where is that package? I can't find it. > > I found it @ http://python-modules.alioth.debian.org/cgi-bin/pet.cgi > under "Ready for upload" section. Seems it's hidden there since > 1 > year :) Ah, it has never been uploaded to the archive, and the ITP was 'timed out'. >>> Now for my questions: >>> - Which one should be renamed? My suggestion is to rename your >>>python-nxt to python-pynxt, since it will get very confusing >>>if there is python-nxt and nxt-python >> There are two rules: >> >> - For python modules, the binary package name should be python-$mod, where >> $mod >> is what you import (so if you do `import nxt`, it should be python-nxt). > > This is the case for my package. I don't know if it's also the case > for pyrtc, but I guess so. > >> - Usually, first come, first serve. So it should be your package that should >> be >> renamed (unless there's a good reason not to). > > As I said I think it's easier to have python-nxt and python-pyrtc > then having python-nxt and nxt-python, since this would be really > confusing IMHO. But perhaps you've got better ideas? Since the other package was never uploaded, I wouldn't have any problem with you taking over that name, but let's hear other opinions. Where does python-pyrtc come from BTW? Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: python-nxt
On Tue, Mar 03, 2009 at 06:20:33PM +0100, Emilio Pozuelo Monfort wrote: > Really? Where is that package? I can't find it. I found it @ http://python-modules.alioth.debian.org/cgi-bin/pet.cgi under "Ready for upload" section. Seems it's hidden there since > 1 year :) > > Now for my questions: > > - Which one should be renamed? My suggestion is to rename your > >python-nxt to python-pynxt, since it will get very confusing > >if there is python-nxt and nxt-python > > There are two rules: > > - For python modules, the binary package name should be python-$mod, where > $mod > is what you import (so if you do `import nxt`, it should be python-nxt). This is the case for my package. I don't know if it's also the case for pyrtc, but I guess so. > - Usually, first come, first serve. So it should be your package that should > be > renamed (unless there's a good reason not to). As I said I think it's easier to have python-nxt and python-pyrtc then having python-nxt and nxt-python, since this would be really confusing IMHO. But perhaps you've got better ideas? -- Sebastian signature.asc Description: Digital signature
Re: python-nxt
Sebastian Reichel wrote: > Hi, > > I'm not in the list, but I hope you will get the mail :) I just > packaged NXT_Python from http://home.comcast.net/~dplau/nxt_python/ > > After this I saw, that one of you packaged pynxt from > https://ssl.natulte.net/nxos/devel and called it python-nxt, > too. Really? Where is that package? I can't find it. > Now for my questions: > - Which one should be renamed? My suggestion is to rename your >python-nxt to python-pynxt, since it will get very confusing >if there is python-nxt and nxt-python There are two rules: - For python modules, the binary package name should be python-$mod, where $mod is what you import (so if you do `import nxt`, it should be python-nxt). - Usually, first come, first serve. So it should be your package that should be renamed (unless there's a good reason not to). Cheers, Emilio signature.asc Description: OpenPGP digital signature
python-nxt
Hi, I'm not in the list, but I hope you will get the mail :) I just packaged NXT_Python from http://home.comcast.net/~dplau/nxt_python/ After this I saw, that one of you packaged pynxt from https://ssl.natulte.net/nxos/devel and called it python-nxt, too. Now for my questions: - Which one should be renamed? My suggestion is to rename your python-nxt to python-pynxt, since it will get very confusing if there is python-nxt and nxt-python - Can you check my package and upload it to debian afterwards? (I'm not a Debian Developer so far - but WIP :)) You can find my work @ http://elektranox.org/debian/python-nxt/ -- Sebastian Reichel signature.asc Description: Digital signature
Life - Un salto nella tua filiera
To view the message, please use an HTML compatible email viewer!
Re: Bzr lightweight checkout, bzr shallow branches, and git
* Adeodato Simó [Tue, 03 Mar 2009 12:04:00 +0100]: > I'll mail upstream about this. Joey Hess beat me to it two weeks ago: http://thread.gmane.org/gmane.comp.version-control.git/110100 The only answer was: AFAIK, it will work in simple cases, but isn't guaranteed to work. Which is a pity, but I think the docs should be updated to explain it better. I'll follow-up to the thread. Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org In my opinion, the most fruitful and natural play of the mind is in conversation. I find it sweeter than any other action in life; and if I were forced to choose, I think I would rather lose my sight than my hearing and voice. -- Michel de Montaigne -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bzr lightweight checkout, bzr shallow branches, and git
On Tue, Mar 3, 2009 at 8:04 PM, Adeodato Simó wrote: > A shallow repository has a number of limitations (you cannot clone > or fetch from it, nor push from nor into it) [...] > ^ > > Can you confirm whether my reading of the underlined part was correct in > assuming it meant you couldn't push from a shallow clone to a full clone? It appears you reading is correct. I thought the docs said something else, although I'm clearly mistaken. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bzr lightweight checkout, bzr shallow branches, and git
* Paul Wise [Tue, 03 Mar 2009 11:30:13 +0900]: > On Tue, Mar 3, 2009 at 1:37 AM, Adeodato Simó wrote: > > 3. Git > > == > > Git has shallow clones, created with the --depth option for git-clone. > > This cut-offs the history of the project past a certain point, but the > > result is lacking: mainly, you cannot push your changes back. (You can > > do local commits however, and you can create patches for this in the > > normal Git workflow.) > This is wrong, you most certainly *can* push from a shallow clone to a > full clone. I think you cannot (yet) push to a shallow clone though > (haven't tried it myself). Thanks for pointing that out: I stand corrected, it seems to work indeed. (Which is awesome, and makes Git's standing on this comparison much better IMHO.) I was guiding myself from the documentation, not having used shallow clones myself. From git-clone(1): A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it) [...] ^ Can you confirm whether my reading of the underlined part was correct in assuming it meant you couldn't push from a shallow clone to a full clone? I'll mail upstream about this. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Any life, no matter how long and complex it may be, is made up of a single moment: the moment in which a man finds out, once and for all, who he is. -- Jorge Luis Borges -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Piotrek's new preferred Python helper tool - (unfair) decision
Le lundi 02 mars 2009 à 16:29 -0800, Steve Langasek a écrit : > > And well, that might make pretty obvious to anyone not convinced yet > > that -central can't really be considered a “chosen one”, no? > > So how does python-support address this bug without instead making > python-based programs excessively brittle during upgrades? It does by running update-python-modules -p with a trigger, that is run after the package’s files have been removed. All symbolic links that point to removed files are then purged. Cheers, -- .''`. Debian 5.0 "Lenny" has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
