NB please stop CCing me and even NeuroDebian team -- both of us (me and Michael) are on the debian-science ML
Oliver -- are you on the list? On Thu, 03 Apr 2014, Andreas Tille wrote: > > Does that mean that you want me to set the debchange back to <version>-1 > > and remove that tag. No problem. I am happy to do that, if that is required. > While required is the wrong word, it is regarded as good practice and > thus I'd recommend it. > > Maybe a stupid question: I simply do not understand this policy. The > > package is already available via NeuroDebian. There was some confusion here. Oliver - you are right with your concern that revering back to -1 would be "incorrect". -1 was already uploaded and accepted to Debian, so the revision could only go forward from here (e.g. to -2 ;)) as it is now in GIT - indeed, tag debian/0.7.0+git34-g55a4e7e-2 was a bit rushed I removed it in that Git repo -- please prune locally as well. I usually tag only after package is uploaded and some times even wait for package to get accepted before I tag/push the tag I will now build/check/upload the package. > That's a good point. I think the NeuroDebian people should take over > here. I was not aware of this and was only speaking from a pure Debian > point of view. I would be happy if NeuroDebian people would come a bit > closer to Debian (keyword "Debian Pure Blend") and do not provoke making > people like me who only know the Debian package pool giving questionable > advise. NeuroDebian would come a bit closer to Debian if "Debian Pure Blend"s come closer ;-) or in other words -- Being "Debian Pure Blend" is nowhere closer than NeuroDebian is already since we feed few blends already, including Debian Science, so this comment I would say is "not appropriate" and not constructive (in my opinion). Leaving (reoccurring) discussion on "Pure Blends vs NeuroDebian" aside for a possible beer-drinking occasion let's continue with technical issues here. > > If I do not make a new > > changelog paragraph, this results in two different initial Debian > > release with exactly same revision number (<version>-1). One here and > > one at NeuroDebian. Is that really intended? > In fact in *this* case you might confuse users who have installed a > (NeuroDebian) package with a certain version number if you deliver > another package with the same version but different content. So in > this specific case we need to derive from the good practice advise. > However, STRONGLY (sorry for shouting but I really mean it that way) > recomment, that NeuroDebian follow the good practice of other > derivatives and create version numbers like > <upstreamversion>-0neurodebian1 > or so. To explain what I mean I write here what I would consider > a sensible changelog for your package: > python-expyriment (0.7.0+git34-g55a4e7e-1) UNRELEASED; urgency=low > * Initial release to Debian (Closes: #742639) > * Add list of exclusions for git > * Add doc-base support > * Add watch file for uscan > * Use the correct URLs for the Vcs-* fields (as per Debian Policy 5.6.26) > * Override the Lintian warning about package section > * add: upstream/metadata > * update doc-base > -- Oliver Lindemann <oliver.lindem...@uni-potsdam.de> Wed, 02 Apr 2014 > 19:12:55 +0200 > python-expyriment (0.7.0+git34-g55a4e7e-0neurodebian1) neurodebian; > urgency=low > * Initial release in NeuroDebian > -- Oliver Lindemann <oliver.lindem...@uni-potsdam.de> Wed, 26 Mar 2014 > 14:35:33 +0100 Backports uploaded to NeuroDebian carry ~nd suffix for Debian revision portion of the package versions, thus sorting "lower" than official version. See e.g. $> acpolicy python-expyriment python-expyriment: Installed: 0.7.0+git34-g55a4e7e-1 Candidate: 0.7.0+git34-g55a4e7e-1 Version table: *** 0.7.0+git34-g55a4e7e-1 0 600 http://debian.lcs.mit.edu/debian/ sid/main amd64 Packages 100 /var/lib/dpkg/status 0.7.0+git34-g55a4e7e-1~nd80+1 0 400 http://neuro.debian.net/debian/ jessie/main amd64 Packages 0.7.0+git34-g55a4e7e-1~nd70+1 0 400 http://neuro.debian.net/debian/ wheezy/main amd64 Packages Thus nothing for anyone preparing for proper Debian upload to take care about really. If next version of package would modify only content of debian/ -- prepare 0.7.0+git34-g55a4e7e-2. If that would be a new upstream 'release' or 'snapshot' prepare e.g. 0.7.1-1 and we (NeuroDebian) will take care about providing backports from NeuroDebian with suffix which would "precede" official version, thus all upgrades etc would work just fine. > The oldest paragraph has a lower version number than "*-1" which enables > a smooth upload to the Debian mirror. It also expresses that the target > release is NOT "unstable" (no idea how NeuroDebian is handling release > names - "unstable" should be reserved for Debian unstable. For instance > Ubuntu is using quantal currently (if I'm not miss leaded). > The current changelog entry contains the changes to the first package > (which makes sense if it was released somewhere) and most importantly > the "Closes: #742639" string. If you want to close a bug in Debian you > should close it in an upload to Debian (for the nitpickers: yes, I'm > aware of alternatives, but I'm describing the usual case for a newbee). > Since the package is not yet released the target distribution should be > "UNRELEASED". In Debian Med we have a workflow that the sponsor will > set this to "unstable" before he is doing the upload. And then, if it would be Debian Med team member to upload straight from GIT -- just let us (NeuroDebian) know and we will upload backport building straight from the uploaded source package. > In general we try to approach packages to be inside Debian first and let > user oriented projects - so called Blends[1] - pick from the official > Debian package pool. NeuroDebian is following this route not that > strictly and thus it might come to some inconsistencies which we > observed now. what inconsistencies? ;) > Sorry if I might have created some confusion on your > side. > Hope this clarification makes sense and that NeuroDebian people take > over now with final sponsering since I'm afraid I might miss some more > pieces of information. oki doki -- will do -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140404011428.gm8...@onerussian.com