Hi.
I took on the task of packaging pd-extended for Debian a couple of months ago and got some help from Hans to get started. While at the Debian Conference 2013, I thought I'd try and see if I could get it ready for upload during this week.
A problem I'm having is with the exectuable for pd-extended. At which end would it be best to change "pd" into "pd-extended"?. I'm thinking this is done in the makefile. Sorry to say, my knowledge of building software with the gnu tools is still elementary.
How is pd-extended maintained, the source itself? The picture I got was that it's puredata plus patches by Hans. In this case, I suppose it would be good to also patch the makefile. Or, is there a reason to keep the executable "pd" by default?
Never mind. I found an option during configuration to solve this problem.
On Mon, Aug 12, 2013, at 09:06 AM, IOhannes m zmölnig wrote:
On 08/11/13 15:03, Kaj Ailomaa wrote:
Never mind. I found an option during configuration to solve this problem.
whatever you are doing, you might also want to check out how we do this in the "puredata" package (where "pd" is renamed to "puredata")
Thanks. I'm studying the puredata rules file. But, not sure yet if I need to use any of that. Well, maybe from where to find the changelog, and such.
As is now, I can change the name of the executable with the configure option --program-suffix. The files always end up in /usr/lib/pd-extended no matter what. Should the config option also change that? However, there seems to be a bug. It changes three files, not only the executable. I solve it by using a postinst script to rename the two files that shouldn't.
Quoting Kaj Ailomaa zequence@mousike.me:
Thanks. I'm studying the puredata rules file. But, not sure yet if I need to use any of that. Well, maybe from where to find the changelog, and such.
whatever pleases you.
As is now, I can change the name of the executable with the configure option --program-suffix. The files always end up in /usr/lib/pd-extended no matter what. Should the config option also change that?
where do you want the lib-stuff to go? /usr/lib/pd-extended seems like the right place to me.
However, there seems to be a bug. It changes three files, not only the executable. I solve it by using a postinst script to rename the two files that shouldn't.
else i'm not sure whether i understand your problem.
in any case, i can only reiterate, that the "puredata" package already handles the renaming properly. the package build process has proven to work for years. i'm pretty sure that you could just take it and do a 's/pure-data/pd-extended/g' on the rules-file.
i figure that the "pd-extended" package will only contain the patched version of Pd (that is: all the externals will be separate packages that are pulled in via dependencies). so the packaging should be virtually the same as for "puredata".
gfmasdr IOhannes
PS: i would highly suggest, recommend or even depend to use "Recommends" for declaring dependencies on externals whenever possible. according to the Debian policy [1], "Recommends [...] declares a strong, but not absolute, dependency". in practice this means that any package-manager (in their default settings) will install the recommended packages, but if the user decides to uninstall one of them, they will not end up with having to decide either to remove Pd-extended completely or end up with a broken system.
[1] http://www.debian.org/doc/debian-policy/ch-relationships.html
On Tue, Aug 13, 2013, at 02:55 AM, zmoelnig@iem.at wrote:
Quoting Kaj Ailomaa zequence@mousike.me:
As is now, I can change the name of the executable with the configure option --program-suffix. The files always end up in /usr/lib/pd-extended no matter what. Should the config option also change that?
where do you want the lib-stuff to go? /usr/lib/pd-extended seems like the right place to me.
Yes. It's the correct place for those files. Just thinking that if using the configure option to add a sufix to the program name also the folder /usr/lib/pd should be renamed /usr/lib/pd-extended. But, since something in the pd-extended source already does this, in some other way - I don't know how, the folder name will never change AFAIK.
However, there seems to be a bug. It changes three files, not only the executable. I solve it by using a postinst script to rename the two files that shouldn't.
else i'm not sure whether i understand your problem.
Currently, my problem is renaming the executable. Building pd-extended will create an exectuable named /usr/bin/pd. Using the configure option -"-program-suffix=-extended" it is renamed to /usr/bin/pd-extended. However, as my bug report shows, two other files get suffixes as well. /usr/lib/pd-extended/bin/pd-watchdog is renamed to /usr/lib/pd-extended/bin/pd-watchdog-extended, and /usr/lib/pd-extended/tcl/pd.gui-tcl is renamed to /usr/lib/pd-extended/tcl/pd-gui.tcl-extended. When starting pd, it won't find those files until they are renamed.
The postinst script is a workaround. I could also use it to rename the executable too of course. My thought was that using the configure option "--program-suffix" would be the best way to rename everything pd into pd-extended. But, maybe not?
in any case, i can only reiterate, that the "puredata" package already handles the renaming properly. the package build process has proven to work for years. i'm pretty sure that you could just take it and do a 's/pure-data/pd-extended/g' on the rules-file.
What is changed in the naming? I haven yet investigated. The executable, or something else?
i figure that the "pd-extended" package will only contain the patched version of Pd (that is: all the externals will be separate packages that are pulled in via dependencies). so the packaging should be virtually the same as for "puredata".
Yes, I believe so. Except, there seems to be some details different in the build process. At least when it comes to naming. I have no clue about what of course.
gfmasdr IOhannes
PS: i would highly suggest, recommend or even depend to use "Recommends" for declaring dependencies on externals whenever possible. according to the Debian policy [1], "Recommends [...] declares a strong, but not absolute, dependency". in practice this means that any package-manager (in their default settings) will install the recommended packages, but if the user decides to uninstall one of them, they will not end up with having to decide either to remove Pd-extended completely or end up with a broken system.
[1] http://www.debian.org/doc/debian-policy/ch-relationships.html
Thanks. I will do that. The idea is that we add a mass of libs to be installed with the package. And using recommends does seem like the best choice.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Quoting Kaj Ailomaa zequence@mousike.me:
I solve it by using a postinst script to rename the two files that shouldn't.
this is most likely the wrong approach.
"postinst" is running on the target system, so instead of renaming the file *once* during the build process, you will rename it thousands of times (on each installation). this also means that you double your chance of creating package collision and circumvent any security measures of the package manager (e.g. apt keeps track of the installed files - but it defers that information from the list of files in the .deb rather than checking which files have been installed after running postinst)
mzdxsf IOhannes
On 08/12/2013 08:59 PM, zmoelnig@iem.at wrote:
Quoting Kaj Ailomaa zequence@mousike.me:
I solve it by using a postinst script to rename the two files that shouldn't.
this is most likely the wrong approach.
"postinst" is running on the target system, so instead of renaming the file *once* during the build process, you will rename it thousands of times (on each installation). this also means that you double your chance of creating package collision and circumvent any security measures of the package manager (e.g. apt keeps track of the installed files - but it defers that information from the list of files in the .deb rather than checking which files have been installed after running postinst)
Ideally, the pd-extended build system would name the executable properly, but it currently does the wrong thing. For the packaging, I think the best thing to do right now is to use a debian/install file to install the file as usr/bin/pd-extended. I think the line in debian/install would look like this:
usr/bin/pd usr/bin/pd-extended
As for basing the pd-extended package off of the 'puredata' package, I think that is not a good idea. The pd-extended package will generate a single package called pd-extended. The puredata package generates lots of sub packages which don't make sense for Pd-extended. Also, Pd-extended's build system (./configure, etc.) is not the same as pd-vanilla's.
.hc
On 08/13/13 23:39, Hans-Christoph Steiner wrote:
Ideally, the pd-extended build system would name the executable properly, but it currently does the wrong thing. For the packaging, I think the best thing to do right now is to use a debian/install file to install the file as usr/bin/pd-extended. I think the line in debian/install would look like this:
usr/bin/pd usr/bin/pd-extended
this unfortunately does not work. you will end up with a file `/usr/bin/pd-extended/pd`
the way it is handled in the `puredata` package is by using the standard configure option `--program-transform-name='s/pd$$/puredata/`
another way would be to override the dh_auto_build target and do the renaming there. a totally untested snippet: <snip> override_dh_auto_build: dh_auto_build cp bin/pd bin/pd-extended </snip>
As for basing the pd-extended package off of the 'puredata' package, I think that is not a good idea. The pd-extended package will generate a single package called pd-extended. The puredata package generates lots of sub packages [...]
ah yes, i was really mainly referring to `debian/rules`
fgmsdr IOhannes
-
Hans-Christoph Steiner -
IOhannes m zmölnig -
Kaj Ailomaa -
zmoelnig＠iem.at