These clearly make sense as standalone libs:
osc
net
cmos
oscillators
tabletools
str
But which, binfile, and midifile might be better in some kind of
library. Like perhaps some kind of 'file' library for binfile and
midifile, that lib could include a whole suite of objects to read
differernt files. Or maybe midifile belongs in a midi lib, which seems
kind of like iemguts, as so on and so forth...
.hc
On Jun 14, 2011, at 12:38 PM, Martin wrote:
Hi IOhannes,
Yes go ahead. I've been wanting to do that as well. The name
'mrpeach' is not very useful.
Martin
On 14/06/11 09:37 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi martin,
in the process of getting numerous pd-libraries into debian (and thus
ubuntu and other debian derivatives), we stumbled upon a small
issue in
your set of objects.
as things are right now, there are no "upstream releases" of your
libraries; in SVN they are organized (as you are well aware) into a
mrpeach/ folder with various task-specific sub-folders.
historically, Pd-extended used the mrpeach/ folder as an
organizational
unit. (install everything you created into a flat extra/mrpeach/
folder)
however, since your libraries don't have anything in common apart
from
you as the author, i would prefer to package them into separate
packages, according to the tasks they are associated with (at least
those where there i a notion of 'library' as is the case with your
net-,
osc-, cmos- objects, so people can install "pd-osc" if they need OSC
communication (and don't need your net/ implementation, as they
intend
to send OSC over serial/slip).
the rough idea is to have packages for
- - OSC
- - net
- - cmos
- - midifile
- - binfile
- - slip
- - str
- - oscillators
- - tabletools
- - which
the debian packages would be named accordingly, with "pd-"
prepended (or
"pd-mrpeach-" for generic names like "tabletools" and
"oscillators", in
order to distinguish them from other libraries that could claim those
generic names with equal rights)
eventually i'm planning to have a "pd-mrpeach" meta-package that
would
depend on all these sub-packages and provide a compatibility layer
for
older (pd-extended) patches.
nothing is required from you to actually _do_ (e.g. code-wise), but
as
hans has correctly pointed out, it would be good to know your
feelings
about all this.
cheers
fgamsdr
IOhannes
On 2011-06-13 17:26, Hans-Christoph Steiner wrote:
Tags: upstream
Since there is no distinct pd-osc upstream, there are no separate
releases from the upstream author only svn, and the only circulating
release is the is the 'mrpeach' library included in Pd-extended, I
think
we need to first get this stuff organized upstream before
uploading a
package to Debian. Have you talked with Martin Peach about it? I
think
it makes sense to have pd-osc, but I think the upstream author
should
determine how the code is released. The 'mrpeach' thing could be
dropped, for example, if Martin wants it that way.
.hc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk33ZAEACgkQkX2Xpv6ydvSN8ACeOL5AKdtccX+xl5Q0xrkoGHnt
QmAAnR1TlHVcbqkaf3DqFdXL2Qsvpm7r
=Wwm4
-----END PGP SIGNATURE-----
----------------------------------------------------------------------------
Looking at things from a more basic level, you can come up with a more
direct solution... It may sound small in theory, but it in practice,
it can change entire economies. - Amy Smith
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
