[PD-dev] deb packages discussion

[dmotd]

please make sure you cc pd-dev too!

Anderson Goulart wrote:
> 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