please make sure you cc pd-dev too! Anderson Goulart wrote: > Hello dmotd, > > On Mon, Sep 21, 2009 at 11:59 AM, dmotd <inaudi...@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
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev