Re: Choosing "proper" Section field (Was: Bug#742639: ITP: python-expyriment -- Python library for cognitive and neuroscientific experiments)
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.lindemann@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.lindemann@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
Reply to: