[PD-dev] deb packages discussion

[Anderson Goulart]

Hello dmotd,

On Mon, Sep 21, 2009 at 11:59 AM, dmotd <inaudible at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20090921/fedb6173/attachment.htm>