Hey all,
For the new 'puredata' package, I think we should add the user- installed paths that have been included with Pd-extended for a while now. Additionally, I'd like to Debianize the directory names (i.e. / usr/lib/puredata) and add /usr/lib/pd-externals for the install path for libraries that can be used with 'puredata', 'pd-extended', 'desiredata', etc.
Here are the user-installed locations: http://www.puredata.info/docs/faq/how-do-i-install-externals-and-help-files-...
The user-installed folders would not be created by the package, just searched if they exist, so people can completely ignore them if they want. I propose the search order look like this:
- paths from preferences ~/pd-externals/ /usr/local/lib/pd-externals /usr/lib/pd-externals /usr/lib/puredata
Ultimately, I think some of this stuff should end up in a 'pd-common' package, including things like the file mime types and the directory / usr/lib/pd-externals.
.hc
----------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
For the new 'puredata' package, I think we should add the user-installed paths that have been included with Pd-extended for a while now. Additionally, I'd like to Debianize the directory names (i.e. / usr/lib/puredata)
What's un-Debian about /usr/lib/pd?
Ciao
On Mon, 30 Nov 2009, Frank Barknecht wrote:
Additionally, I'd like to Debianize the directory names (i.e. / usr/lib/puredata)
What's un-Debian about /usr/lib/pd?
the package name is not "pd".
alternatively, the package name could be changed, if there is no nameclash.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard wrote:
On Mon, 30 Nov 2009, Frank Barknecht wrote:
Additionally, I'd like to Debianize the directory names (i.e. / usr/lib/puredata)
What's un-Debian about /usr/lib/pd?
the package name is not "pd".
the package name used to be "pd"
alternatively, the package name could be changed, if there is no nameclash.
it was changed to "puredata", which seems to be meant as the specific name (e.g. pd-vanilla). i think the idea is, that several packages (puredata, PdX), can be installed either side-by-side or exclusively, and packages depending on "pd" (which the various flavours "provide") will still have their dependencies fullfilled.
however, i don't see a really compelling reason why things should be moved from /usr/lib/pd to /usr/lib/puredata. it might be sufficient to symlink from /u/l/puredata to /u/l/pd for now. or the other way round.
/usr/lib/pd should be kept.
ah, and there is a tool to test for compliance with debian rules: lintian you can make it very picky (telling it to show not only errors and ordinary warnings, but also "pedantic" warnings and "experimental" inconsistencies). the puredata package i posted on mentors (still pending a mentor though), is lintian clean in this regard, even though it installs into /u/l/pd
i wouldn't change anything without a compelling reason.
fgmasdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
however, i don't see a really compelling reason why things should be moved from /usr/lib/pd to /usr/lib/puredata. it might be sufficient to symlink from /u/l/puredata to /u/l/pd for now. or the other way round.
/usr/lib/pd should be kept.
AFAIK not even the Debian policy requires the "lib"-directory name to be the same as the package name. It sometimes talks about "preferably" choosing the package name for certain directory names in /etc/ /usr/share or /usr/lib, but I found no mentioning of "required". X11, vim, emacs are examples, where the directory-name is not the same as the package name. There is no "X11" package, the "emacs" package is an empty meta package and the "vim" package is just one of many vims available in Debian - and the one, that does *not* include /usr/share/vim.
To my knowledge the policy isn't violated - but I'm no Debian maintainer in training, so I may be wrong. But still the current package has no open bug about this, the pure:dyne packages use "pd" as well. Btw: What about these packages? Weren't the p:d maintainers planning to incorporate their packages into Debian proper as well? Is there cooperation between HCS' efforts and those in pure:dyne?
Ciao
On Dec 1, 2009, at 5:04 AM, Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
however, i don't see a really compelling reason why things should be moved from /usr/lib/pd to /usr/lib/puredata. it might be sufficient to symlink from /u/l/puredata to /u/l/pd for now. or the other way round.
/usr/lib/pd should be kept.
AFAIK not even the Debian policy requires the "lib"-directory name to be the same as the package name. It sometimes talks about "preferably" choosing the package name for certain directory names in /etc/ /usr/share or /usr/ lib, but I found no mentioning of "required". X11, vim, emacs are examples, where the directory-name is not the same as the package name. There is no "X11" package, the "emacs" package is an empty meta package and the "vim" package is just one of many vims available in Debian - and the one, that does *not* include /usr/share/vim.
To my knowledge the policy isn't violated - but I'm no Debian maintainer in training, so I may be wrong. But still the current package has no open bug about this, the pure:dyne packages use "pd" as well. Btw: What about these packages? Weren't the p:d maintainers planning to incorporate their packages into Debian proper as well? Is there cooperation between HCS' efforts and those in pure:dyne?
The pure:dyne developers have been very quiet on this topic. I've been posting here in the hopes that they would join in the conversation. pd-dev seems like a natural place for this conversation, no?
.hc
----------------------------------------------------------------------------
Mistrust authority - promote decentralization. - the hacker ethic
On Dec 1, 2009, at 3:22 AM, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
On Mon, 30 Nov 2009, Frank Barknecht wrote:
Additionally, I'd like to Debianize the directory names (i.e. / usr/lib/puredata)
What's un-Debian about /usr/lib/pd?
the package name is not "pd".
the package name used to be "pd"
alternatively, the package name could be changed, if there is no nameclash.
it was changed to "puredata", which seems to be meant as the specific name (e.g. pd-vanilla). i think the idea is, that several packages (puredata, PdX), can be installed either side-by-side or exclusively, and packages depending on "pd" (which the various flavours "provide") will still have their dependencies fullfilled.
however, i don't see a really compelling reason why things should be moved from /usr/lib/pd to /usr/lib/puredata. it might be sufficient to symlink from /u/l/puredata to /u/l/pd for now. or the other way round.
/usr/lib/pd should be kept.
ah, and there is a tool to test for compliance with debian rules: lintian you can make it very picky (telling it to show not only errors and ordinary warnings, but also "pedantic" warnings and "experimental" inconsistencies). the puredata package i posted on mentors (still pending a mentor though), is lintian clean in this regard, even though it installs into /u/l/pd
i wouldn't change anything without a compelling reason.
The compelling reason is that 'pd' means multiple packages 'puredata', 'pd-extended', and perhaps others. Where is the harm in changing this? Its a trivial patch, its not a directory that people should be ever changing since its managed by the packages. If it causes problems, we can change it back. Here's an example:
desiredata: /usr/lib/desiredata puredata: /usr/lib/pd pd-extended: /usr/lib/pd-extended libraries install path: /usr/lib/pd-externals
.hc
----------------------------------------------------------------------------
kill your television
Hans-Christoph Steiner wrote:
The compelling reason is that 'pd' means multiple packages 'puredata', 'pd-extended', and perhaps others. Where is the harm in changing this?
but there are so many trivial patches in the world that won't do no harm to anybody. this is not a reason to apply them "just so".
i understand that /u/l/puredata seems to be more natural than /u/l/pd. however, so far _this_ hasn't caused any problems i know of yet. so why change it? if it does cause problem and changing it to /usr/lib/puredata would fix them, then i don't see a reason not to change it.
Its a trivial patch, its not a directory that people should be ever changing since its managed by the packages. If it causes problems, we can change it back.
who? it's naturally easy, if you are already debian developer. if you are not, it is rather hard (i know that the debcon is in ny, and you will be a full fledged dd in 3 weeks or so; but not yet) the experiences i made so far with mentors are rather unsatisfying in this regard that is: i haven't found a sponsor yet to upload either the new release of puredata nor of gem. with this in mind, the solution you suggest is rather illusory.
Here's an example:
desiredata: /usr/lib/desiredata puredata: /usr/lib/pd pd-extended: /usr/lib/pd-extended libraries install path: /usr/lib/pd-externals
an example for what?
here's another example: desiredata: /usr/lib/desiredata puredata: /usr/lib/pd pd-extended: /usr/lib/pd-extended libraries install path: /usr/lib/pd
mfgsdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
The compelling reason is that 'pd' means multiple packages 'puredata', 'pd-extended', and perhaps others. Where is the harm in changing this?
but there are so many trivial patches in the world that won't do no harm to anybody. this is not a reason to apply them "just so".
i understand that /u/l/puredata seems to be more natural than /u/l/pd. however, so far _this_ hasn't caused any problems i know of yet. so why change it? if it does cause problem and changing it to /usr/lib/puredata would fix them, then i don't see a reason not to change it.
Its a trivial patch, its not a directory that people should be ever changing since its managed by the packages. If it causes problems, we can change it back.
Wow, that's a cute attitude for a maintainer!
Renaming "/u/l/pd" to "/u/l/puredata" is a solution in search of a problem. Pd upstream uses /usr/(local/)lib/pd for ages. All documentation is written with this in mind, many Makefiles use it as default. The only reason why someone may consider to use /usr/(local/)lib/puredata instead is that the Debian package is called "puredata". But this is a very specific peculiarity of this particular distribution. Miller's source archive is called "pd", the autobuilds use "pd" or for Pd-extended "Pd-<version>-extended" which is a completely illegal package name as far as Debian's policy is concerned btw.
If you want to support and package the various forks of Pd, then the only thing you need to do is make a meta package "pd" and let all forks provide "pd", and that's already done and in fact is the reason for Debian's pd package carrying the name "puredata"! It's no problem to have them all use a shared directory for extensions as far as Debian and the filesystem is concerned. I mentioned the vim packages as an example. If you want fork-specific data, you can always add special directories in these packages, like /usr/lib/puredata-extended
Ciao
On Dec 2, 2009, at 4:11 AM, Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
The compelling reason is that 'pd' means multiple packages 'puredata', 'pd-extended', and perhaps others. Where is the harm in changing this?
but there are so many trivial patches in the world that won't do no harm to anybody. this is not a reason to apply them "just so".
i understand that /u/l/puredata seems to be more natural than /u/l/ pd. however, so far _this_ hasn't caused any problems i know of yet. so why change it? if it does cause problem and changing it to /usr/lib/puredata would fix them, then i don't see a reason not to change it.
Its a trivial patch, its not a directory that people should be ever changing since its managed by the packages. If it causes problems, we can change it back.
Wow, that's a cute attitude for a maintainer!
Renaming "/u/l/pd" to "/u/l/puredata" is a solution in search of a problem. Pd upstream uses /usr/(local/)lib/pd for ages. All documentation is written with this in mind, many Makefiles use it as default. The only reason why someone may consider to use /usr/(local/)lib/puredata instead is that the Debian package is called "puredata". But this is a very specific peculiarity of this particular distribution.
An example of a problem this is trying to solve: if 'puredata' is at version 0.42.5 and 'pdextended' and 'desiredata' are not at 0.42.5 yet, then there would be an incompatibility in the 'extra' objects that are in the /usr/lib/pd/extra. Another possible approach would be making a 'pd-extra' package that has that stuff in it. That would have to be packaged so that its loadable as a distinct library to make it work, as far as I can see.
Miller's source archive is called "pd", the autobuilds use "pd" or for Pd-extended "Pd-<version>-extended" which is a completely illegal package name as far as Debian's policy is concerned btw.
Yes, that's just old crufty scripts, the official releases are all done right. They are in the SVN in scripts/auto-build for anyone who wants to fix them.
If you want to support and package the various forks of Pd, then the only thing you need to do is make a meta package "pd" and let all forks provide "pd", and that's already done and in fact is the reason for Debian's pd package carrying the name "puredata"! It's no problem to have them all use a shared directory for extensions as far as Debian and the filesystem is concerned. I mentioned the vim packages as an example. If you want fork-specific data, you can always add special directories in these packages, like /usr/lib/puredata- extended
You highlight the core of the issue: there is a common understanding of what /usr/lib/pd means in the Debian packaging. That meaning was defined by a single 'pd' package. There is now 'puredata' and 'pd- extended' packages and a 'desiredata' one would nice, so we can all benefit from a plan to have library packages that work for all. But that means the definition of /usr/lib/pd has to be changed. We discussed these this at the last PdCon, and there was agreement on the fact that the three directories are needed. So then we have three directories that overlap the meaning of the original /usr/lib/pd:
1. a /usr/lib directory for objects that work for everything that provides 'pd' 2. a /usr/lib directory for objects that work only for 'puredata' 3. a /usr/lib directory for objects that work only for 'pd-extended'
I am ok with keeping /usr/lib/pd as the first directory since it matches the virtual package 'pd'. (Previously we'd decided on /usr/ lib/pd-externals as the name for the first directory). In terms of the packaged libraries, using /usr/lib/pd for the first directory means the existing ones don't have to change unless they are incompatible with Pd-extended/DesireData. But that means changing the 'puredata' package to use /usr/lib/puredata for the stuff that comes in pd/extra (i.e. bonk~, etc).
I tried to start encapsulating these discussions here, please add things: http://puredata.info/dev/DebianPackagingStructure
.hc
----------------------------------------------------------------------------
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
But that means the definition of /usr/lib/pd has to be changed. We discussed these this at the last PdCon, and there was agreement on the fact that the three directories are needed. So then we have three directories that overlap the meaning of the original /usr/lib/pd:
- a /usr/lib directory for objects that work for everything that
provides 'pd' 2. a /usr/lib directory for objects that work only for 'puredata' 3. a /usr/lib directory for objects that work only for 'pd-extended'
I am ok with keeping /usr/lib/pd as the first directory since it matches the virtual package 'pd'.
(Previously we'd decided on /usr/ lib/pd-externals as the name for the first directory). In terms of the packaged libraries, using /usr/lib/pd for the first directory means the existing ones don't have to change unless they are incompatible with Pd-extended/DesireData.
I think, this makes sense and I'd go that way as well. But not only because of the name of the virtual package, also because "pd" is just *the* name for this, like "X11" is *the* name for everything regarding X software, even when no package carries that name anymore.
Now that we have new players like maybe desiredata, they can and should use their custom directories if they need to, but this should not directly affect the old ones.
A different issue is version changes. Here a possibility could be to follow examples like Vim or Python, which use a versioned subdirectories like /usr/share/vim/vim71/ or /usr/lib/python2.5/site-packages.
But that means changing the 'puredata' package to use /usr/lib/puredata for the stuff that comes in pd/extra (i.e. bonk~, etc).
This I don't understand. They are externals, but they work and come with the original, vanilla Pd. In my opinion they can and should stay in /usr/lib/pd
Ciao
On Thu, 3 Dec 2009, Frank Barknecht wrote:
Now that we have new players like maybe desiredata, they can and should use their custom directories if they need to, but this should not directly affect the old ones.
Well, at some point 'vi' became 'vim' and that was reflected in the names of folders, but for desiredata I don't have much of a wish to keep things separate... the GUI externals will need a separate folder, but I don't see us separating the whole lot of externals just because of the 5% of them that need to be compiled differently.
If ever I finish the API for deallocating symbols, though, it could be different, but this is all too hypothetical.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Dec 3, 2009, at 9:22 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
But that means the definition of /usr/lib/pd has to be changed. We discussed these this at the last PdCon, and there was agreement on the fact that the three directories are needed. So then we have three directories that overlap the meaning of the original /usr/lib/pd:
- a /usr/lib directory for objects that work for everything that
provides 'pd' 2. a /usr/lib directory for objects that work only for 'puredata' 3. a /usr/lib directory for objects that work only for 'pd-extended'
I am ok with keeping /usr/lib/pd as the first directory since it matches the virtual package 'pd'.
(Previously we'd decided on /usr/ lib/pd-externals as the name for the first directory). In terms of the packaged libraries, using /usr/lib/ pd for the first directory means the existing ones don't have to change unless they are incompatible with Pd-extended/DesireData.
I think, this makes sense and I'd go that way as well. But not only because of the name of the virtual package, also because "pd" is just *the* name for this, like "X11" is *the* name for everything regarding X software, even when no package carries that name anymore.
Now that we have new players like maybe desiredata, they can and should use their custom directories if they need to, but this should not directly affect the old ones.
A different issue is version changes. Here a possibility could be to follow examples like Vim or Python, which use a versioned subdirectories like /usr/share/vim/vim71/ or /usr/lib/python2.5/site-packages.
But that means changing the 'puredata' package to use /usr/lib/puredata for the stuff that comes in pd/extra (i.e. bonk~, etc).
This I don't understand. They are externals, but they work and come with the original, vanilla Pd. In my opinion they can and should stay in /usr/ lib/pd
The problem is versioning. One of the goals of Pd-extended is to be compatible with the same version of Pd-vanilla, i.e. Pd-extended 0.40.3 can run anything that Pd-vanilla 0.40.3 can. I imagine that desiredata has a similar goal, but maybe not. The objects in 'extra' are part of what Pd-vanilla 0.40.3 provides.
So if the objects in extra come with the 'puredata' package and are put into the common /usr/lib/pd directory, then the 'pdextended' and 'desiredata' packages would use the versions that come with 'puredata'. So that means they would need to be removed from the 'pdextended' and 'desiredata' packages. That's not a big deal, I am ok with that. But the problem is that if 'puredata' gets updated to 0.43 while 'pdextended' is still at 0.42, and 'puredata' puts the 'extra' externals into the shared directory. Then 'pdextended' can't be 0.42 compatible anymore.
One idea is to package Pd vanilla's 'extra' separately, i.e. 'pd- extra'. Then 'puredata' can Recommend 'pd-extra' and 'pdextended' can Conflict with 'pd-extra' and I can make versioned packages for 'pdextended', ie 'pd-extra042'. Another is to have the extra folder from 'puredata' in /usr/lib/puredata.
By the way, is anyone from pure:dyne listening? It would be great to have some input from you.
.hc
----------------------------------------------------------------------------
Access to computers should be unlimited and total. - the hacker ethic
Some quick comments..
Hans-Christoph Steiner wrote:
By the way, is anyone from pure:dyne listening? It would be great to have some input from you.
1. The paths stuff: the status quo is fine, I don't understand what you are trying to fix at all, apart from disruptive "change for the sake of change" to make a name more perceptually uniform - wtf does that solve?
2. it was taking too long for us to get packages into Debian
3. Puredyne (Ubuntu Karmic based distro) packages are here: https://launchpad.net/~puredyne-team/+archive/ppa
4. The Puredyne pd-foo external packages "Depends: puredata" (afaik).
5. Maybe it would be better for puredata and pd-extended to both "Provide: pd", but then pd-extended will have a long "Conflicts: .." list, which is a pain for things like pd-gridflow "Depends: pd-gem, puredata" which means Puredyne pd-gridflow won't work with Pd-extended unless Pd-extended "Provides: pd-gem", then things will crash if the respective Pd ABIs are different, etc...
5.b. There must be a good elegant technical solution out there somewhere, but so far the "accidental workaround" of Puredyne's pd and externals packages basically conflicting with Pd-extended completely, hasn't caused too many problems in the wild: either have Puredyne puredata and modular externals, xor have Pd-extended monolith - choose your poison..
Claude
On Dec 3, 2009, at 9:28 PM, Claude Heiland-Allen wrote:
Some quick comments..
Hans-Christoph Steiner wrote:
By the way, is anyone from pure:dyne listening? It would be great to have some input from you.
- The paths stuff: the status quo is fine, I don't understand what
you are trying to fix at all, apart from disruptive "change for the sake of change" to make a name more perceptually uniform - wtf does that solve?
The problem was outlined in this thread, and in previous discussions. How to handle the objects in 'extra' and the versioning requirements. More uniform naming is only an added benefit.
it was taking too long for us to get packages into Debian
Puredyne (Ubuntu Karmic based distro) packages are here:
https://launchpad.net/~puredyne-team/+archive/ppa
- The Puredyne pd-foo external packages "Depends: puredata" (afaik).
For them to become generic packages that work with 'puredata', 'pdextended', 'desiredata', they would need to depend on 'pd'.
- Maybe it would be better for puredata and pd-extended to both
"Provide: pd", but then pd-extended will have a long "Conflicts: .." list, which is a pain for things like pd-gridflow "Depends: pd-gem, puredata" which means Puredyne pd-gridflow won't work with Pd- extended unless Pd-extended "Provides: pd-gem", then things will crash if the respective Pd ABIs are different, etc...
I think this assumes that Pd-extended is a monolithic package, which it will not be. I think that 'puredata' and 'pdextended' both can provide 'pd' and be installed into separate directories. I am ok with making 'puredata' use /usr/bin/pd and 'pdextended' use /usr/bin/ pdextended. /usr/bin/pd could be handled by /etc/alternatives so that people can provide which flavor is tied to the 'pd' command.
5.b. There must be a good elegant technical solution out there somewhere, but so far the "accidental workaround" of Puredyne's pd and externals packages basically conflicting with Pd-extended completely, hasn't caused too many problems in the wild: either have Puredyne puredata and modular externals, xor have Pd-extended monolith - choose your poison..
AFAIK, no one thinks the big monolithic package is a good idea for Debian/Ubuntu. That's why we are having this discussion. I think this path issue is really the only think I would add to the pure:dyne approach. The other would be building things as a single-binary- single-object format for objects in externals except objects that won't work in that format (i.e. the objects like [>~] or [/~]). Aliases can be made to work in this format too, I'll do the work there.
.hc
----------------------------------------------------------------------------
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
The problem is versioning. One of the goals of Pd-extended is to be compatible with the same version of Pd-vanilla, i.e. Pd-extended 0.40.3 can run anything that Pd-vanilla 0.40.3 can. I imagine that desiredata has a similar goal, but maybe not. The objects in 'extra' are part of what Pd-vanilla 0.40.3 provides.
Okay, now here's an issue: I agree that the objects in "extra" are something, that "pd" should provide. But if the packages "pdextended" and "desiredata" provide "pd" they also have to provide, say, expr.pd_linux, even if "puredata" is not installed. This gets even hairier with things like helpfiles: a package that provides "pd" should include and provide route-help.pd, of which we have a different one in PDDP which maybe is part of "pdextended.deb" (or maybe isn't).
So if the objects in extra come with the 'puredata' package and are put into the common /usr/lib/pd directory, then the 'pdextended' and 'desiredata' packages would use the versions that come with 'puredata'. So that means they would need to be removed from the 'pdextended' and 'desiredata' packages.
If "pdx" and "dd" provide "pd" and if "providing pd" includes providing an [expr] object, then you can't do that, see above.
That's not a big deal, I am ok with that. But the problem is that if 'puredata' gets updated to 0.43 while 'pdextended' is still at 0.42, and 'puredata' puts the 'extra' externals into the shared directory. Then 'pdextended' can't be 0.42 compatible anymore.
You can do versioned dependencies with Debian ("Depends: pd >= 0.44"), but of course a package that provides "X" itself cannot depend on "X >= y.z" in a sensible way.
One idea is to package Pd vanilla's 'extra' separately, i.e. 'pd-extra'. Then 'puredata' can Recommend 'pd-extra' and 'pdextended' can Conflict with 'pd-extra' and I can make versioned packages for 'pdextended', ie 'pd-extra042'. Another is to have the extra folder from 'puredata' in /usr/lib/puredata.
"pdextended" could also a) depend on "puredata == 0.42", so that it gets deinstalled or updated, when a newer "puredata" is installed, or b) it could be completely independent of "puredata" (i.e. have its own "expr.pd_linux") or c) it could conflict, replace and provide "pd" so that you can only install one. Maybe there are some other possibilities.
Ciao
On Dec 5, 2009, at 7:51 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
The problem is versioning. One of the goals of Pd-extended is to be compatible with the same version of Pd-vanilla, i.e. Pd-extended 0.40.3 can run anything that Pd-vanilla 0.40.3 can. I imagine that desiredata has a similar goal, but maybe not. The objects in 'extra' are part of what Pd-vanilla 0.40.3 provides.
Okay, now here's an issue: I agree that the objects in "extra" are something, that "pd" should provide. But if the packages "pdextended" and "desiredata" provide "pd" they also have to provide, say, expr.pd_linux, even if "puredata" is not installed. This gets even hairier with things like helpfiles: a package that provides "pd" should include and provide route-help.pd, of which we have a different one in PDDP which maybe is part of "pdextended.deb" (or maybe isn't).
So if the objects in extra come with the 'puredata' package and are put into the common /usr/lib/pd directory, then the 'pdextended' and 'desiredata' packages would use the versions that come with 'puredata'. So that means they would need to be removed from the 'pdextended' and 'desiredata' packages.
If "pdx" and "dd" provide "pd" and if "providing pd" includes providing an [expr] object, then you can't do that, see above.
That's not a big deal, I am ok with that. But the problem is that if 'puredata' gets updated to 0.43 while 'pdextended' is still at 0.42, and 'puredata' puts the 'extra' externals into the shared directory. Then 'pdextended' can't be 0.42 compatible anymore.
You can do versioned dependencies with Debian ("Depends: pd >= 0.44"), but of course a package that provides "X" itself cannot depend on "X >= y.z" in a sensible way.
One idea is to package Pd vanilla's 'extra' separately, i.e. 'pd- extra'. Then 'puredata' can Recommend 'pd-extra' and 'pdextended' can Conflict with 'pd-extra' and I can make versioned packages for 'pdextended', ie 'pd-extra042'. Another is to have the extra folder from 'puredata' in /usr/lib/puredata.
"pdextended" could also a) depend on "puredata == 0.42", so that it gets deinstalled or updated, when a newer "puredata" is installed, or
That would work, but it seems to me that it should be possible to have each 'pd' package independent, which I think is desireable. I think that putting the docs and 'extra' stuff into each package's /usr/lib/ (puredata, pdextended, desiredata) will work the best with the fewest disadvantages. Then libraries will have their help patches with them wherever they are installed.
b) it could be completely independent of "puredata" (i.e. have its own "expr.pd_linux")
So how then to have shared library packages?
c) it could conflict, replace and provide "pd" so that you can only install one.
This sounds like a bad option to me, I think the problems of getting them working together are not very hard, we just need to agree on the approach.
.hc
Maybe there are some other possibilities.
Ciao
Frank
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
On Dec 2, 2009, at 3:33 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
The compelling reason is that 'pd' means multiple packages 'puredata', 'pd-extended', and perhaps others. Where is the harm in changing this?
but there are so many trivial patches in the world that won't do no harm to anybody. this is not a reason to apply them "just so".
i understand that /u/l/puredata seems to be more natural than /u/l/pd. however, so far _this_ hasn't caused any problems i know of yet. so why change it? if it does cause problem and changing it to /usr/lib/puredata would fix them, then i don't see a reason not to change it.
Its a trivial patch, its not a directory that people should be ever changing since its managed by the packages. If it causes problems, we can change it back.
who? it's naturally easy, if you are already debian developer. if you are not, it is rather hard (i know that the debcon is in ny, and you will be a full fledged dd in 3 weeks or so; but not yet) the experiences i made so far with mentors are rather unsatisfying in this regard that is: i haven't found a sponsor yet to upload either the new release of puredata nor of gem. with this in mind, the solution you suggest is rather illusory.
You don't need to be a DD to upload packages, you can be a Debian Maintainer, that's the route that I am going for now, much lower hurdle. You then need a DD sponsor to add new packages, but you can upload updates to existing packages directly. I recommend that you go for that as well, but I am ok with doing the uploads if I am the only one.
http://www.debian.org/devel/join/newmaint
By the way, could you check in your files for the package into packages/debian? That seems to be a natural place to Or do you maintain them elsewhere (i.e. besides in the package itself)?
.hc
Here's an example:
desiredata: /usr/lib/desiredata puredata: /usr/lib/pd pd-extended: /usr/lib/pd-extended libraries install path: /usr/lib/pd-externals
an example for what?
here's another example: desiredata: /usr/lib/desiredata puredata: /usr/lib/pd pd-extended: /usr/lib/pd-extended libraries install path: /usr/lib/pd
mfgsdr IOhannes
----------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Mon, 30 Nov 2009, Frank Barknecht wrote:
Additionally, I'd like to Debianize the directory names (i.e. / usr/lib/puredata)
What's un-Debian about /usr/lib/pd?
the package name is not "pd".
There also is no "X11" package.
Ciao
On Nov 30, 2009, at 6:33 PM, Mathieu Bouchard wrote:
On Mon, 30 Nov 2009, Frank Barknecht wrote:
Additionally, I'd like to Debianize the directory names (i.e. / usr/lib/puredata)
What's un-Debian about /usr/lib/pd?
the package name is not "pd".
alternatively, the package name could be changed, if there is no nameclash.
There is a nameclash. 'pd' is a virtual package for library packages to depend on. 'puredata' and 'pd-extended' provide 'pd. A 'desiredata' package could also provide 'pd'. Then library packages would install properly with any or all Pd flavors installed.
.hc
----------------------------------------------------------------------------
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Nov 30, 2009, at 6:33 PM, Mathieu Bouchard wrote:
On Mon, 30 Nov 2009, Frank Barknecht wrote:
Additionally, I'd like to Debianize the directory names (i.e. / usr/lib/puredata)
What's un-Debian about /usr/lib/pd?
the package name is not "pd".
alternatively, the package name could be changed, if there is no nameclash.
There is a nameclash. 'pd' is a virtual package for library packages to depend on. 'puredata' and 'pd-extended' provide 'pd. A 'desiredata' package could also provide 'pd'. Then library packages would install properly with any or all Pd flavors installed.
So doesn't it make sense to keep "pd" as a name for the lib-directory, just like "vim" in /usr/share/vim is the common install place for all flavours of Vim (i.e. vim, vim-gnome, vim-gtk, vim-lesstif etc.)?
Ciao
-
Claude Heiland-Allen -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard