Bug#915553: ITP: pd-csound -- Csound external for Pure Data

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig <***@debian.org>

* Package name : pd-csound
Version : 1.01.0
Upstream Author : Victor Lazzarini et al.
* URL : https://csound.com
* License : LGPL
Programming Lang: C
Description : Csound external for Pure Data
This is the csound6~ object for Pure Data.
.
For more information on Csound or Pure Data, see the respective packages.

pd-csound used to be built from the csound (source) package, but upstream has
factored it out into a separate project (starting with fresh veresion numbers).
This is an attempt to bring the package back in.

I intend to maintain this under tha multimedia-team umbrella.

gfmdstr
IOhannes

[IOhannes m zmölnig (Debian/GNU)]

Post by IOhannes m zmoelnig
Package: wnpp
* Package name : pd-csound
Version : 1.01.0
pd-csound used to be built from the csound (source) package, but upstream has
factored it out into a separate project (starting with fresh version numbers).
This is an attempt to bring the package back in.

stretch features a pd-csound binary package built from "csound" with a
version number "1:6.08.0~dfsg-1".

upstream has factored out this component into a separate project (and
therefore pd-csound is currently no more in buster), starting with a new
version (1.01.0).

as mandated by the policy, i'd like to discuss, whether an epoch bump
for the new source package "pd-csound" (to be "2:1.01.0-1") is
warranted, or indeed a good idea.

the first version of Csound in Debian seems to have been "3.484.0d-1"
(according to snapshot.d.o), with pd-csound appearing at "1:5.08.0.dfsg2-1".

the factored out project is relatively new, i don't know how the
versions will evolve.

fgmasdr
IOhannes

[Simon McVittie]

Post by IOhannes m zmölnig (Debian/GNU)

Post by IOhannes m zmoelnig
Package: wnpp
* Package name : pd-csound
Version : 1.01.0
pd-csound used to be built from the csound (source) package, but upstream has
factored it out into a separate project (starting with fresh version numbers).
This is an attempt to bring the package back in.

stretch features a pd-csound binary package built from "csound" with a
version number "1:6.08.0~dfsg-1".
upstream has factored out this component into a separate project (and
therefore pd-csound is currently no more in buster), starting with a new
version (1.01.0).

I would suggest talking to the upstream developer of pd-csound. It seems
reasonably likely that their users will be confused by the fact that
that version 1.01.0 of the "Csound external" (I assume that's some sort
of loadable module, analogous to a Python module?) is newer/better than
version 6.08.0 of the Csound external, despite its lower version number?

If they agree that this is confusing, they might be willing to re-version
to 7.01.0 or something, so that version numbers keep going up.

If they are unwilling to change the version number, then bumping the
epoch seems like a correct Debian-level workaround for the version
numbering scheme having been reset.

smcv

[IOhannes m zmölnig (Debian/GNU)]

Post by Simon McVittie
I would suggest talking to the upstream developer of pd-csound. It seems
reasonably likely that their users will be confused by the fact that
that version 1.01.0 of the "Csound external" (I assume that's some sort
of loadable module, analogous to a Python module?) is newer/better than
version 6.08.0 of the Csound external, despite its lower version number?
If they agree that this is confusing, they might be willing to re-version
to 7.01.0 or something, so that version numbers keep going up.
If they are unwilling to change the version number, then bumping the
epoch seems like a correct Debian-level workaround for the version
numbering scheme having been reset.
The version was always 1.00 even when it was inside Csound. Minor
changes made it go to 1.01 when we moved it out. It is not the same as
the Csound version. So I am not really keen on changing this.

so it seems that the Debian *binary* package should have used a
different version than the source package in the first place.

it also gives me confidence, that the upstream version number will not
increment much in the next time, which should keep us safe from re-using
the same version (without epoch)

gfadsmr
IOhannes

[Adam Borowski]

Post by IOhannes m zmölnig (Debian/GNU)

Post by Simon McVittie
If they agree that this is confusing, they might be willing to re-version
to 7.01.0 or something, so that version numbers keep going up.
If they are unwilling to change the version number, then bumping the
epoch seems like a correct Debian-level workaround for the version
numbering scheme having been reset.
The version was always 1.00 even when it was inside Csound. Minor
changes made it go to 1.01 when we moved it out. It is not the same as
the Csound version. So I am not really keen on changing this.

so it seems that the Debian *binary* package should have used a
different version than the source package in the first place.
it also gives me confidence, that the upstream version number will not
increment much in the next time, which should keep us safe from re-using
the same version (without epoch)

There already is an epoch, you can't remove it. On the other hand, with the
damage already done, there's little reason not to bump it.


Meow!

[Simon McVittie]

Post by Adam Borowski

Post by IOhannes m zmölnig (Debian/GNU)

Post by Simon McVittie
The version was always 1.00 even when it was inside Csound. Minor
changes made it go to 1.01 when we moved it out. It is not the same as
the Csound version. So I am not really keen on changing this.

so it seems that the Debian *binary* package should have used a
different version than the source package in the first place.
it also gives me confidence, that the upstream version number will not
increment much in the next time, which should keep us safe from re-using
the same version (without epoch)

Based on what upstream said, I agree: go ahead with epoch 2. Thanks for
checking here and with upstream before uploading.

Post by Adam Borowski
There already is an epoch, you can't remove it. On the other hand, with the
damage already done, there's little reason not to bump it.

That's also a reasonable factor to take into account, and in this case
it leads to the same conclusion.

smcv

[Sean Whitton]

Hello,

Post by Simon McVittie

Post by Adam Borowski
There already is an epoch, you can't remove it. On the other hand, with the
damage already done, there's little reason not to bump it.

That's also a reasonable factor to take into account, and in this case
it leads to the same conclusion.

Indeed, although it should be noted that Policy does require -devel
consultation even for a bump (as IOhannes is clearly aware).

[Paul Gevers]

Hi,

Post by IOhannes m zmölnig (Debian/GNU)
as mandated by the policy, i'd like to discuss, whether an epoch bump
for the new source package "pd-csound" (to be "2:1.01.0-1") is
warranted, or indeed a good idea.

Can at least the source package not carry the any special epoch, or is
that too confusing?

Paul

[IOhannes m zmölnig (Debian/GNU)]

Post by Paul Gevers
Hi,

Post by IOhannes m zmölnig (Debian/GNU)
as mandated by the policy, i'd like to discuss, whether an epoch bump
for the new source package "pd-csound" (to be "2:1.01.0-1") is
warranted, or indeed a good idea.

Can at least the source package not carry the any special epoch, or is
that too confusing?

is there any advantage of this?

the source package currently only builds a single binary package (and i
don't expect this to change).
so i think that having different version numbers for source and binary
package to only add complexity to the packaging with little gain.


i have already uploaded to NEW yesterday (after the discussion here
seemed to indicate consensus on the epoch bump), but of course it's
awaiting ftp-masters' approval, so there is still time to re-upload.

fgamsdr
IOhannes