On Tue, 3 Jul 2007, Roman Häfeli wrote:
On Tue, 2007-07-03 at 12:56 +0200, IOhannes m zmoelnig wrote:
i think it would be interesting to split pd and pd-gui into 2 separate packages (pd recommending pd-gui, pd-gui probably depending on pd (but not necessarily)). right now, you can run pd with "-nogui", but due to all the dependencies in the package, you will have to install X, tk and so on. (correct me if i am wrong, i haven't checked)
i think, this is a good idea. puredata depends on tk8.4 depends on libx11-6 depends on x11-common etc. so yes, in order to install pd now, the whole x window system is installed.
I don't see what's the problem. You don't have to install the whole X Window System, because it's already installed anyway.
Unless you ran out of diskettes.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Wed, Jul 04, 2007 at 04:37:26PM -0400, Mathieu Bouchard wrote:
On Tue, 3 Jul 2007, Roman HÀfeli wrote:
On Tue, 2007-07-03 at 12:56 +0200, IOhannes m zmoelnig wrote:
i think it would be interesting to split pd and pd-gui into 2 separate packages (pd recommending pd-gui, pd-gui probably depending on pd (but not necessarily)). right now, you can run pd with "-nogui", but due to all the dependencies in the package, you will have to install X, tk and so on. (correct me if i am wrong, i haven't checked)
i think, this is a good idea. puredata depends on tk8.4 depends on libx11-6 depends on x11-common etc. so yes, in order to install pd now, the whole x window system is installed.
I don't see what's the problem. You don't have to install the whole X Window System, because it's already installed anyway.
Unless you ran out of diskettes.
Or you are running on a headless embedded system[1], or a flash-ROM based system with no X[2].
Chris.
[1] http://www.linuxdevices.com/news/NS7851725125.html [2] http://en.wikipedia.org/wiki/Gp2x
On Wed, 4 Jul 2007, Chris McCormick wrote:
On Wed, Jul 04, 2007 at 04:37:26PM -0400, Mathieu Bouchard wrote:
I don't see what's the problem. You don't have to install the whole X Window System, because it's already installed anyway.
Or you are running on a headless embedded system[1], or a flash-ROM based system with no X[2].
With a headless embedded system you still benefit from having libX11 because then its applications can display windows on the screen of the computer that you use to connect to it. I do that using "ssh -X -C".
Does that system even support deb or rpm ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Wed, Jul 04, 2007 at 11:42:12PM -0400, Mathieu Bouchard wrote:
On Wed, 4 Jul 2007, Chris McCormick wrote:
On Wed, Jul 04, 2007 at 04:37:26PM -0400, Mathieu Bouchard wrote:
I don't see what's the problem. You don't have to install the whole X Window System, because it's already installed anyway.
Or you are running on a headless embedded system[1], or a flash-ROM based system with no X[2].
With a headless embedded system you still benefit from having libX11 because then its applications can display windows on the screen of the computer that you use to connect to it. I do that using "ssh -X -C".
If you want to do that then you need to have an X server running right? In some situations that consumes more memory, CPU, flash/disk than is desireable. Is there any other advantage to having libX11, tcl/tk, etc. other than wanting to ssh -X -C?
I do take your point, but I think you aren't considering all possible applications and environments that Pd might potentially be a part of.
Does that system even support deb or rpm ?
Not now, but it probably will when Open2x have done their work.
Best,
Chris.
On Thu, 5 Jul 2007, Chris McCormick wrote:
With a headless embedded system you still benefit from having libX11 because then its applications can display windows on the screen of the computer that you use to connect to it. I do that using "ssh -X -C".
If you want to do that then you need to have an X server running right?
You need an X server on the ssh client side. An X client does not connect where you don't tell it to connect. Most of the time that I use "ssh -X -C", I don't have an X server on the machine that runs the X client; and I mean that not only it's not in RAM, it's not on disk either.
Is there any other advantage to having libX11, tcl/tk, etc. other than wanting to ssh -X -C?
you can also connect directly by X11 protocol for the same reason that you can still use Telnet or RSH if you really want to.
I do take your point, but I think you aren't considering all possible applications and environments that Pd might potentially be a part of.
Does that system even support deb or rpm ?
Not now, but it probably will when Open2x have done their work.
Then you can probably re-mention it when they are done with their work if people still use it with 64MB flash. (On the other machine that you mentioned, diskspace is not even an issue.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Thu, Jul 05, 2007 at 12:11:46AM -0400, Mathieu Bouchard wrote:
On Thu, 5 Jul 2007, Chris McCormick wrote:
With a headless embedded system you still benefit from having libX11 because then its applications can display windows on the screen of the computer that you use to connect to it. I do that using "ssh -X -C".
If you want to do that then you need to have an X server running right?
You need an X server on the ssh client side. An X client does not connect where you don't tell it to connect. Most of the time that I use "ssh -X -C", I don't have an X server on the machine that runs the X client; and I mean that not only it's not in RAM, it's not on disk either.
Yep, good point.
I do take your point, but I think you aren't considering all possible applications and environments that Pd might potentially be a part of.
Then you can probably re-mention it when they are done with their work if people still use it with 64MB flash. (On the other machine that you mentioned, diskspace is not even an issue.)
Your argument seems to be this: any machine that is sufficiently equipped to run debian/ubuntu should not have a problem running X applications, and hence we should force users to install tcl/tk and X when installing pd.
Just because you can't conceive of a concrete example where someone wants to run debian/ubuntu, but can't, or doesn't want to install X, doesn't mean that it won't happen. Anyone who does a lot of development on embedded systems knows that at least having the option of being able to install and run the most minimal configuration of a piece of software is very valuable for those corner cases where you simply must have it that way. I can't list those corner cases for you because I am not clever enough to see the future, but my past experience indicates that they will probably exist.
It seems like you are arguing for software bloat, against modularity and against user choice, and I don't understand why you would argue that. If that is your position then we will have to agree to disagree.
Best,
Chris.
On Thu, 5 Jul 2007, Chris McCormick wrote:
Just because you can't conceive of a concrete example where someone wants to run debian/ubuntu, but can't, or doesn't want to install X, doesn't mean that it won't happen. Anyone who does a lot of development on embedded systems knows that at least having the option of being able to install and run the most minimal configuration of a piece of software is very valuable for those corner cases
It's not that: it's that people who run debian/ubuntu and don't want to install X but want to use pd, are precisely the kind of people who will not use those packages, because they will want to remove some more guts from it.
It seems like you are arguing for software bloat, against modularity and against user choice, and I don't understand why you would argue that.
I'm arguing against making special efforts to provide features to people who won't use them.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Thu, Jul 05, 2007 at 01:48:38AM -0400, Mathieu Bouchard wrote:
On Thu, 5 Jul 2007, Chris McCormick wrote:
Just because you can't conceive of a concrete example where someone wants to run debian/ubuntu, but can't, or doesn't want to install X, doesn't mean that it won't happen. Anyone who does a lot of development on embedded systems knows that at least having the option of being able to install and run the most minimal configuration of a piece of software is very valuable for those corner cases
It's not that: it's that people who run debian/ubuntu and don't want to install X but want to use pd, are precisely the kind of people who will not use those packages, because they will want to remove some more guts from it.
It seems like you are arguing for software bloat, against modularity and against user choice, and I don't understand why you would argue that.
I'm arguing against making special efforts to provide features to people who won't use them.
Ok, yes, I see.
Chris.
On Wed, 2007-07-04 at 16:37 -0400, Mathieu Bouchard wrote:
On Tue, 3 Jul 2007, Roman HÀfeli wrote:
On Tue, 2007-07-03 at 12:56 +0200, IOhannes m zmoelnig wrote:
i think it would be interesting to split pd and pd-gui into 2 separate packages (pd recommending pd-gui, pd-gui probably depending on pd (but not necessarily)). right now, you can run pd with "-nogui", but due to all the dependencies in the package, you will have to install X, tk and so on. (correct me if i am wrong, i haven't checked)
i think, this is a good idea. puredata depends on tk8.4 depends on libx11-6 depends on x11-common etc. so yes, in order to install pd now, the whole x window system is installed.
I don't see what's the problem. You don't have to install the whole X Window System, because it's already installed anyway.
Unless you ran out of diskettes.
yo, i think there are some situations (e.g. for a fixed installation), where you know in advance that you'll run pd with -nogui and you setup a fresh computer just for this installtion (e.g. ubuntu server, which has no X per default, afaik). why would you want to install X then, when you won't need it? for this kind of cases (i already had some of them), now you are forced to install the complete X windows system, when you install pd per package manager. it would be nice to have the opportunity to install purely puredata.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Thu, 5 Jul 2007, Roman Haefeli wrote:
yo, i think there are some situations (e.g. for a fixed installation), where you know in advance that you'll run pd with -nogui and you setup a fresh computer just for this installtion (e.g. ubuntu server, which has no X per default, afaik). why would you want to install X then, when you won't need it? for this kind of cases (i already had some of them), now you are forced to install the complete X windows system, when you install pd per package manager. it would be nice to have the opportunity to install purely puredata.
As I have said in another mail in this thread, a dependency on tk on results on X client components (libX11 and friends) to be installed. The X server (incl drivers and fonts) is not a dependency.
Installing those extra packages takes one minute and zero effort. In the meanwhile you don't even have the time to go grab a coffee from your very own kilowatt drip machine.
OTOH, it wouldn't really hurt much if the package was split.
The main advantage that I'd see to splitting pd into several packages is that it would be much more visible in the package selection systems; but that doesn't necessarily correlate much to new users, especially for very specialised, high-training apps like pd. It'd likely be much more fruitful to use keywords in a way that people susceptible of being good at pd can discover the existence of pd just by searching for what they like in their package manager.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Thu, Jul 05, 2007 at 02:50:22PM -0400, Mathieu Bouchard wrote:
OTOH, it wouldn't really hurt much if the package was split.
Now that you have finally conceded that splitting the package wouldn't be such a bad thing, and several others have indicated that it would be a good thing for them, can we please put this thread to rest and get on with making the software more modular and flexible, and giving the user the choices they want.
Best,
Chris.
On Thu, 5 Jul 2007, Chris McCormick wrote:
On Thu, Jul 05, 2007 at 02:50:22PM -0400, Mathieu Bouchard wrote:
OTOH, it wouldn't really hurt much if the package was split.
Now that you have finally conceded that splitting the package wouldn't be such a bad thing, and several others have indicated that it would be a good thing for them, can we please put this thread to rest and get on with making the software more modular and flexible, and giving the user the choices they want.
Hey, it's not like I'm the one who makes debian packages or like what I'm saying is preventing the splitting of debian packages.
Now, what about putting each object class of pd in a different package? This would give the user a lot more choice, modularity is flexibility.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Thu, Jul 05, 2007 at 10:59:47PM -0400, Mathieu Bouchard wrote:
Now, what about putting each object class of pd in a different package?
I am assuming you mean a different package for each [osc~] [cos] [+] etc.
This would give the user a lot more choice, modularity is flexibility.
But it doesn't seem very practical. Can you tell me of any user who wants that amount of flexibilty and choice?
Chris.
On Fri, 2007-07-06 at 05:54 -0400, Chris McCormick wrote:
On Thu, Jul 05, 2007 at 10:59:47PM -0400, Mathieu Bouchard wrote:
Now, what about putting each object class of pd in a different package?
I am assuming you mean a different package for each [osc~] [cos] [+] etc.
This would give the user a lot more choice, modularity is flexibility.
But it doesn't seem very practical. Can you tell me of any user who wants that amount of flexibilty and choice?
i'd say, matju's question was more a rhetorical one. why not giving each object class its own pacakage, since this would give you the highest possible amount of flexibility?
i personally would enjoy separate packages for pd and pd-gui, but i most often compile pd myself, so either way wouldn't harm me much. however, i suppose everyone could live with either way.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
i personally would enjoy separate packages for pd and pd-gui, but i most often compile pd myself, so either way wouldn't harm me much. however, i suppose everyone could live with either way.
I guess, 98 percent of the users of Pd use both the pd-gui and the Pd main binary. Forcing them to install two instead of one package to me doesn't look practical.
To satisfy the other two percent, a better solution IMO would be to make a pd-nogui patckage, that would conflict with the normal Pd package, so that only one can be installed. This has predecessors in the various flavours of vi(m) and emacs that can be chosen on Debian.
All this of course should be decided by the makers of a distribution and the respective maintainers to not violate their policies.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
I guess, 98 percent of the users of Pd use both the pd-gui and the Pd main binary. Forcing them to install two instead of one package to me doesn't look practical.
To satisfy the other two percent, a better solution IMO would be to make a pd-nogui patckage, that would conflict with the normal Pd package, so that only one can be installed. This has predecessors in the various flavours of vi(m) and emacs that can be chosen on Debian.
All this of course should be decided by the makers of a distribution and the respective maintainers to not violate their policies.
How about splitting it into two packages, pd-nogui.deb and pd.deb, so pd would depend on pd-nogui.deb. It's like installing (e.g.) gvim, which depends on vim-common, that contains a console version of vim.
cu Thomas
"Prisons are needed only to provide the illusion that courts and police are effective. They're a kind of job insurance." (Leto II. in: Frank Herbert, God Emperor of Dune) http://thomas.dergrossebruder.org/
Hallo, Thomas Mayer hat gesagt: // Thomas Mayer wrote:
Frank Barknecht wrote:
To satisfy the other two percent, a better solution IMO would be to make a pd-nogui patckage, that would conflict with the normal Pd package, so that only one can be installed. This has predecessors in the various flavours of vi(m) and emacs that can be chosen on Debian.
How about splitting it into two packages, pd-nogui.deb and pd.deb, so pd would depend on pd-nogui.deb. It's like installing (e.g.) gvim, which depends on vim-common, that contains a console version of vim.
No, vim-common does not contain the console version of vim. vim-common only holds the data shared by all vim packages, like help-files. The actual binaries of vim are in the packages called vim, vim-gtk, vim-tiny, vim-python etc. Among these, the package "vim" provides a vim binary with the most standard feature set. The other packages are for people who "need more (or less)".
That could be a useful solution for Pd as well, however I'd rather see work being done on splitting off a package of just the externals from pd-extended than bothering too much with making the main pd package even smaller, when those (few), who need that, can just roll their own.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Fri, 6 Jul 2007, Chris McCormick wrote:
On Thu, Jul 05, 2007 at 10:59:47PM -0400, Mathieu Bouchard wrote:
Now, what about putting each object class of pd in a different package?
I am assuming you mean a different package for each [osc~] [cos] [+] etc.
That's what I mean.
This would give the user a lot more choice, modularity is flexibility.
grrr, typo, change "is" to "and", to match what you had said before.
But it doesn't seem very practical. Can you tell me of any user who wants that amount of flexibilty and choice?
Let's wait a bit, there must be someone. However it doesn't mean we'd find that person right away... not even 2% of pd users write on pd-list. Personally I'm interested in rationales used in a feature acceptance process. It's not really a rhetorical question, because I'm really interested in answers.
If we compare pd-extended to how Debian/Ubuntu packages are structured for programming languages like Perl, Python, Tcl, Ruby, PHP, etc., then pd-extended would be a few dozen packages already.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Fri, Jul 06, 2007 at 11:15:05AM -0400, Mathieu Bouchard wrote:
If we compare pd-extended to how Debian/Ubuntu packages are structured for programming languages like Perl, Python, Tcl, Ruby, PHP, etc., then pd-extended would be a few dozen packages already.
That seems the most sensible approach for Pd in Debian to me - several packages; one for each group of similar externals and each libray. One package for each object class, if you want to call them that, seems like overkill though. Infact in Debian Etch you can currently install:
gem - Graphics Environment for Multimedia - PureData library pd-aubio - aubio external for PureData puredata - realtime computer music and graphics system pd-zexy - Addon library for Pd
Not sure exactly why we're having this conversation since it seems to be taken care of quite capably by GG already.
Best,
Chris.
On Jul 9, 2007, at 1:39 AM, Chris McCormick wrote:
On Fri, Jul 06, 2007 at 11:15:05AM -0400, Mathieu Bouchard wrote:
If we compare pd-extended to how Debian/Ubuntu packages are
structured for programming languages like Perl, Python, Tcl, Ruby, PHP, etc., then pd-extended would be a few dozen packages already.That seems the most sensible approach for Pd in Debian to me - several packages; one for each group of similar externals and each libray. One package for each object class, if you want to call them that, seems like overkill though. Infact in Debian Etch you can currently install:
gem - Graphics Environment for Multimedia - PureData library pd-aubio - aubio external for PureData puredata - realtime computer music and graphics system pd-zexy - Addon library for Pd
Not sure exactly why we're having this conversation since it seems
to be taken care of quite capably by GG already.
It would be nice to have the rest of the libraries as Debian
packages. What's available now is just a small subset of what should
be there.
Any volunteers? The package I made is just a quick hack to make
things easier to install. I hope it gets replaced soon.
.hc
Best,
Chris.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
-
Chris McCormick -
Frank Barknecht -
Hans-Christoph Steiner -
Mathieu Bouchard -
Roman Haefeli -
Thomas Mayer