Hello dmotd,

On Mon, Sep 21, 2009 at 11:59 AM, dmotd <inaudible@simplesuperlativ.es> wrote:
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.


why do you think so? Manage the repo is easy.. reprepro can do this for us easily...
the dificult part will be generate debian/ dir to all externals and make a standard to put things on the correct places...
in this part I think that would not be a big problem also, because all externals (or almost all) has autotools build system... with some templates we can manage a task force on the weekend to do this handfull job..
 
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.


ow... i would like to see what you are doing.. maybe will help us to separate things.. can you share?
 
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).


so.. on those packages we can distribute the work to someone with more expertise or we can help each other to manage that... but, with separate things, it is easier to deal with a problem than in a huge build farm .. .
 
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).


pd-extended is successful because users can install and use it... they do not care about what kind of build systems the developers are using or dealing with...
I think hans made a very good work, but increasing the number of packages will become harder to maintain in a monolict way.. that's my opinion...
 
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.


so we got the point... the users view is the key... all of the work is done for them... because for us we can just compile all the stuff ourselves..
as a user, pd-extended installs and load too much externals.. why can't we do such a thing that the user can choose what he wants? Like: i need pd+gem+fann ... can I have it only?

 
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.


Maybe it is a good idea, but i have no idea how they built this server.. and thinking in users, it is easier to install via apt-get than cpan specific commands.. because who uses debian/ubuntu are used to it.
 
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?


well.. meta-packages or categories are just a user point of view.. we can create many as we or users want... like

pd-full
pd-audio
pd-video
pd-math
...

this is not a problem at all..
 
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.


I think a simplistic way is the best way.. always.. :D Why transform a simple step harder or more complex?
But I really understand the work you, Hans and others had in pd packaging and this is why I just throw the dicussion here.. I needed to know what is going on before working alone on an idea...
 
but if you care to go over some of your ideas with
a bit more detail we may find something
interesting to work with.

I think I was clear about my ideas. Make a debian package for every external or join only some related to a deb file.

And there are some others key points:

1) make a single documentation teaching how developers can build or create their own packages
2) remove "m_pd.h" from externals and use <m_pd.h> (why do I need to have PD source to compile my external? This should be installed as any other library and linked with -l option; the m_pd.h should be installed on /usr/include also)
3) fix many build systems to work in any platafform (like adding -fPIC for AMD64 every time we need to compile on this plattaform is so anoying.. we can make it automatic or add something like --arch option)
3.1) Some build systems use a variable to point where is the pd source. This is bizarre for me... let's make a pd shared library and link to it...
4) distribute some files:
.orig.tar.gz with the clean source to help others to create their own build (like ebuild on gentoo or slackpkg)
.dsc and deb - debianized package


that is it for now..

bye, global