Hello Roman,
I assume you tried downloading the package through HTTP. There is an info link next to the download, md5 and APT links on the download page, that links here: http://pd.ianagnostopoulos.postgrad.shef.ac.uk/notes.txt
This describes the dependencies, and gives you another link, http://pd.ianagnostopoulos.postgrad.shef.ac.uk/pd-deps.tar which contains a tar archive with the three packages of the dependencies.
If you try getting it through the OtherSide APT, the dependencies are there and thus automatically configured.
These three packages have been removed from the official Ubuntu (and I think also Debian) repositories since no package there depended on them. My understanding is that they are NOT replaced by the ones you mentioned. I tried simply changing the dependencies to the newer versions and it installed, but came up with many errors when launching PD.
GEM seems to need the specific versions it depends on. I think that since there is no "serious" reason not to use these libraries, it doesn't make sense doing anything to the source code to make it compatible with the newer versions. If we simply provide these extra packages with the PD package, by hosting them on the same places, it will be fine. Since nothing else has anything to do with them, they won't break anything.
-Ilias
On Mon, 2008-12-01 at 17:54 +0000, Ilias Anagnostopoulos wrote:
Hello Roman,
I assume you tried downloading the package through HTTP.
exactly.
There is an info link next to the download, md5 and APT links on the download page, that links here: http://pd.ianagnostopoulos.postgrad.shef.ac.uk/notes.txt
This describes the dependencies, and gives you another link, http://pd.ianagnostopoulos.postgrad.shef.ac.uk/pd-deps.tar which contains a tar archive with the three packages of the dependencies.
If you try getting it through the OtherSide APT, the dependencies are there and thus automatically configured.
i see. cool work you did!
These three packages have been removed from the official Ubuntu (and I think also Debian) repositories since no package there depended on them. My understanding is that they are NOT replaced by the ones you mentioned. I tried simply changing the dependencies to the newer versions and it installed, but came up with many errors when launching PD.
i see..
GEM seems to need the specific versions it depends on. I think that since there is no "serious" reason not to use these libraries, it doesn't make sense doing anything to the source code to make it compatible with the newer versions. If we simply provide these extra packages with the PD package, by hosting them on the same places, it will be fine. Since nothing else has anything to do with them, they won't break anything.
right..
thanks for your detailed answer and the work you put it.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Ilias Anagnostopoulos wrote:
Hello Roman,
GEM seems to need the specific versions it depends on. I think that since there is no "serious" reason not to use these libraries, it doesn't make sense doing anything to the source code to make it compatible with the newer versions. If we simply provide these extra packages with the PD package, by hosting them on the same places, it will be fine. Since nothing else has anything to do with them, they won't break anything.
i don't think that Gem explicitely needs magick9 rather than magick10. here (debian lenny/sid) i am using imagemagick++10 and everything wors fine.
as for limpeg3 vs libmpeg1: these are not just versions, thes are completely different libraries. replaying the one with the other will certainly make your nose bleed. Gem has source-code support for both libraries. i don't see a reason to remove support for libmpeg1, just because it is no longer packaged. nevertheless, i also don't see any reason why someone should provide a precompiled binary of Gem _with_ support for libmpeg1 (i think it is quite buggy).
so, from my (Gem) side of things: all maintainers of packages should use the latest and greatest available packages of their distribution and not require outdated packages for Gem just because they can :-)
thanks for all your work
gfmadsr IOhannes
Hello IOhannes,
I will check it again tomorrow and if I can make a better solution work, I'll implement it.
As for the libmpeg1 vs libmpeg3, how would I specify which one I want to use then? Or does it figure this out on its own at compile time?
-Ilias
IOhannes m zmoelnig wrote:
Ilias Anagnostopoulos wrote:
Hello Roman,
GEM seems to need the specific versions it depends on. I think that since there is no "serious" reason not to use these libraries, it doesn't make sense doing anything to the source code to make it compatible with the newer versions. If we simply provide these extra packages with the PD package, by hosting them on the same places, it will be fine. Since nothing else has anything to do with them, they won't break anything.
i don't think that Gem explicitely needs magick9 rather than magick10. here (debian lenny/sid) i am using imagemagick++10 and everything wors fine.
as for limpeg3 vs libmpeg1: these are not just versions, thes are completely different libraries. replaying the one with the other will certainly make your nose bleed. Gem has source-code support for both libraries. i don't see a reason to remove support for libmpeg1, just because it is no longer packaged. nevertheless, i also don't see any reason why someone should provide a precompiled binary of Gem _with_ support for libmpeg1 (i think it is quite buggy).
so, from my (Gem) side of things: all maintainers of packages should use the latest and greatest available packages of their distribution and not require outdated packages for Gem just because they can :-)
thanks for all your work
gfmadsr IOhannes
Ilias Anagnostopoulos wrote:
Hello IOhannes,
I will check it again tomorrow and if I can make a better solution work, I'll implement it.
As for the libmpeg1 vs libmpeg3, how would I specify which one I want to use then? Or does it figure this out on its own at compile time?
it should automatically disable libmpeg1 if libmpeg3 is found (but not very careful crafting has been spent on this).
if there is no libmpeg1 available, Gem will build without. (if there is no libmpeg3 available, Gem will build without)
you can manually disable support for certain libraries by using configure-flags: "--without-mpeg1" will do...
fgmasr IOhannes
Thanks, I will try this as soon as possible and sort it out as appropriate. I will let you know what the results are.
-Ilias
IOhannes m zmoelnig wrote:
Ilias Anagnostopoulos wrote:
Hello IOhannes,
I will check it again tomorrow and if I can make a better solution work, I'll implement it.
As for the libmpeg1 vs libmpeg3, how would I specify which one I want to use then? Or does it figure this out on its own at compile time?
it should automatically disable libmpeg1 if libmpeg3 is found (but not very careful crafting has been spent on this).
if there is no libmpeg1 available, Gem will build without. (if there is no libmpeg3 available, Gem will build without)
you can manually disable support for certain libraries by using configure-flags: "--without-mpeg1" will do...
fgmasr IOhannes
-
Ilias Anagnostopoulos -
IOhannes m zmoelnig -
Roman Haefeli