[PD-dev] deb packages discussion

[dmotd]

i guess i understand where you're coming from and 
in some ways i think you are right, however 
packaging debs is not as simple as it seems and 
with the sheer size of the externals repo what you 
are suggesting would get quite unmanageable.

for the record, i am currently working on a 
slightly revised build system and part of the aim 
of that is to modularize the building process, so 
that assembling pd as a series of parts will 
become easier and more configurable. automating a 
set of debian rules would hopefully be a lot less 
time consuming once this work is complete.

this may knock over a part of the problem, but 
there are a lot of libraries that require less 
generalized appoaches and need careful attention 
from a packager (which can become a time consuming 
role).

this is part of the reason why pd-extended is a 
very successful package - it knocks out a lot of 
the maintenance hastles by automating as much of 
the build procedure as possible, and although as a 
whole it is quite monalythic, the same set of 
objects can be reliably assumed across each 
platform (or in linux terms each variety of 
distribution). it's not perfect but it makes sense 
for most people - and many thanks to hans for 
getting it this far (its a pretty thankless job).

perhaps what should be asked is what is required 
from pd to make it a full featured language for 
people to practically use it for whatver meets a 
general set of needs? for many people what miller 
packages as his own 'vanilla' set is all that is 
required and everything else is extraneous. for a 
lot of people with complex goals that just doesn't 
cut it and extended is necessary to work beyond 
pd's own limitations.
 
or pehaps pd could go down the path of perl/cpan, 
php/pear etc, where extra non-base libs are housed 
in a dedicated on demand server where users can 
automagically fetch / compile and install extras 
outside of the confines of a package manager.

or do you want there to be categorized libs for 
different areas of programming, what should be 
installed by default with the meta package, and 
what happens to objects that don't neatly slot 
into a category - or worse fulfil a number of 
categories?

these are just a few arguments that i think are 
stumbling blocks for your proposal. its not to say 
that its a dumb idea, but perhaps a little 
simplistic and something which has already met a 
lot of conentious discussion on this and other 
forums.

but if you care to go over some of your ideas with 
a bit more detail we may find something 
interesting to work with.
--
dmotd.

Anderson Goulart wrote:
> Hello IOhannes,
> 
> thanks for your answer...
> 
> On Mon, Sep 21, 2009 at 4:08 AM, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:
> 
>     Anderson Goulart wrote:
> 
>         Hello all,
> 
> 
>         puredata-ext-XX - package containing a single external
>         puredata-abs-XX - package containing a single abstraction
> 
> 
>     why do you want to separate them? 
> 
>     how does a "single external" differ (substantially) from a "single
>     abstraction"? (esp. since .deb takes care of platform-in/dependency)
> 
> 
> 
> Well, this is just an ideia and we can decide to use names like puredata-xxx,
> where xxx is the name of external/abstraction. What I want here is to discuss
> the conventions about packaging things related to Pd.
> 
>  
> 
>     do you really want to distribute a _single_ file with an entire .deb or do
>     you rather mean "library"?
> 
> 
> 
> Maybe we can distribute  a "library" if those externals/abstractions are
> related. But if they are different, with different upstream authors, with
> different dependencies and different funcionalities, I think distribute an
> entire .deb is better than put it together in a library.
> 
>  
> 
>     how does this integrate into the already existing debian infrastructure for
>     Pd? e.g. with naming schemes like "pd-zexy" or "pd-gem" (that is: why do we
>     want to reinvent the wheel?)
> 
> 
> 
> I am not a debian developer, but I am sure we can talk to them to upload all
> packages to the official repo. The naming conventions are just suggestions and
> we can use pd-xxx instead of puredata-xxx. The main idea of this email is to
> separate pd-extended into some .deb packages to become more clear and easier to
> maintain to many architectures and distribution versions.
> 
> 
> bye, global