How hard is to use the Windows method(1) for Linux and OSX? If pd finds the dependency in the same dir as the external isn`t it more “easy and robust” than depending on an Internet connection?. Especially for the cases than one have to run a patch in a machine somewhere depending only on a pendrive. It also don't need the new proposed Deken pkg dependency.txt

(1) recently mentioned by Thomashttps://github.com/pure-data/pure-data/commit/5dadaf43c9206823b434d11c6cc6c6...

Mensaje telepatico asistido por maquinas.

To: pd-list@lists.iem.at From: zmoelnig@iem.at Date: Mon, 18 Jul 2016 16:00:53 +0200 Subject: Re: [PD] Deken and Dependencies

On 07/18/2016 03:13 PM, Thomas Mayer wrote:

• For Linux (and Mac OS X?) do not package the shared libraries

for OSX *do* package the shared libraries after making them "local", following something along the lines of [1]

i know for a fact that the proposed solution does work. why do you want to suggest otherwise?

gfdsar IOhannes

[1] http://gem.iem.at/documentation/faq/how-do-i-make-library-dependencies-local...

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

on linux: use apt (or yum/emerge/pacman) instead to install any pdexternals. this is *way* better and much more secure than shipping 3rdparty libraries. Instead of Deken? Where does the dep lib goes, to the same folder as the external? Or to an Os system folder <--- this is what is not useful for the pendrive example. Mensaje telepatico asistido por maquinas.

under unix system lib dep is managed by OS but on windows it's a growing pletora off dll everywhere tha sucks hard drive space for the sake of hardware vendors

We are not talking about hardware and microsoft, we are taking about pd externals dlls. I have cheked all w32 deken pkgs and mainly the only one dll that is going to be dup/multiply is pthread and there will be around 15 copies of it. All deken packages count 2100 dlls [objects] and takes around 150Mb. PthreadGC2 is 93Kb and there are (will be) 15 of them.

Mensaje telepatico asistido por maquinas.

To: pd-list@lists.iem.at From: colet.patrice@free.fr Date: Tue, 19 Jul 2016 03:04:08 +0200 Subject: Re: [PD] Deken and Dependencies

Le 19/07/2016 à 00:48, Lucas Cordiviola a écrit :

...

/on linux: use apt (or yum/emerge/pacman) instead to install any pd/
/externals. this is *way* better and much more secure than
shipping 3rd/
/party libraries./

Instead of Deken?

Where does the dep lib goes, to the same folder as the external? Or to an Os system folder <--- this is what is not useful for the pendrive example.

under unix system lib dep is managed by OS but on windows it's a growing pletora off dll everywhere tha sucks hard drive space for the sake of hardware vendors

...

Mensaje telepatico asistido por maquinas.

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

-- Patrice Colet fr: 0632660357

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

On 2016-07-19 00:48, Lucas Cordiviola wrote:

on linux: use apt (or yum/emerge/pacman) instead to install any pdexternals. this is *way* better and much more secure than shipping 3rdparty libraries. Instead of Deken?

no. *with* deken.

$ sudo apt-get install pd-deken-apt

fgmasdr IOhannes

On 07/19/2016 06:51 PM, Lucas Cordiviola wrote:

what?

Does Deken pass that command to Linux Os when you use Deken gui?

deken has a plugin-system to add additional sources for externals. the only one that i know of is for "apt", which allows you to search/install the Debian/Ubuntu/... packages.

and of course, you can still install "normal deken packages" (pre-built binaries from puredata.info).

gfmrdsa IOhannes

On 07/19/2016 08:51 PM, Lucas Cordiviola wrote:

/>deken has a plugin-system to add additional sources for externals.
the/
/>only one that i know of is for "apt", which allows you to
search/install/
/>the Debian/Ubuntu/... packages./

Lets put aside this option for clarity as I don`t get it. This downloads all sources and compiles on target machine? Where does the 3th pty Lib goes?

no it uses the package manager to install the libraries and all dependencies.

Lets focus on this as is more useful for normal users:

/>and of course, you can still install "normal deken packages"
(pre-built/
/>binaries from puredata.info)./

I think that NOT SHIPING 3th pty Libs contradicts *your* very good idea that a Deken pkg must be “self operational”. Someone wants to distribute a patch and includes the external and the 3th pty Lib, the patch simply opens and works, thats all.

he/she has simply got those files from the Deken pkg.

Why NOT shiping 3th pty libs on Linux?

note: i'm *not totally* (though kind of strongly) opposed to shipping 3rd party libs on linux. my point is mainly, that in the linux ecosystem this is not the "standard" way (unlike on osx and w32). virtually all linux distros make it very easy to install virtually any library from trusted sources: # apt-get install libfoo (this is very unlike on e.g. w32, where people do a quick google search for pthreadGC2.dll and blindly download it from megaupload or the like).

afaict, there is only a handful of externals that actually do require 3rd party libraries on linux, and afaik all of them are pretty well supported by the various distro package.

gfmsa IOhannes

(1) Since I have tested all w32 pkgs, I can easily prepare a Mapping for that, if you specify some protocol.

Sorry that has already been done.

Mensaje telepatico asistido por maquinas.

From: lucarda27@hotmail.com To: pd-list@lists.iem.at Date: Tue, 19 Jul 2016 19:49:17 +0000 Subject: Re: [PD] Deken and Dependencies

note: i'm *not totally* (though kind of strongly) opposed to shipping>3rd party libs on linux.>my point is mainly, that in the linux ecosystem this is not the>"standard" way (unlike on osx and w32).>virtually all linux distros make it very easy to install virtually any>library from trusted sources:># apt-get install libfoo

Please reconsider your opposition. This is about Deken pkgs not “standard” ways of anything. If someone distributes a patch that uses [x~] deken will not find that yet(1), that's why he/she has included the object and if necessary the 3th pty Lib. You just open the abs and pd finds and loads everything. (1) Since I have tested all w32 pkgs, I can easily prepare a Mapping for that, if you specify some protocol.

Mensaje telepatico asistido por maquinas.

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

This also makes more economy/efficient the process of sharing abs. As you don't have to download all pkg for just one object, so less stress/energy bill to puredata.info, and also you don't have to do all -path -lib and reopen pd.

Mensaje telepatico asistido por maquinas.

From: lucarda27@hotmail.com To: pd-list@lists.iem.at Date: Tue, 19 Jul 2016 20:29:00 +0000 Subject: Re: [PD] Deken and Dependencies

I mean I prepare a patch that you just open and works, if you don't have [x~] I have already prepared the [declare] and included the external and it's 3th pty Lib. I have prepared everything using Deken so that you don't have to install anything.

Mensaje telepatico asistido por maquinas.

and of course, whoever creates a deken package is encouraged to do>whatever possible within the current format to get their thing running>as smooth as possible (and if this includes bundling 3rd party libraries>for 5 OSs and 18 architectures, then so be it).>>what my opposition is directed at is adding cruft to the pd-core to>allow for deviant packaging practices.

What will be the problem for a linux system to look for the 3th party Lib in the same folder as the ext (which needs it) if it can't find anywhere else in the local system? IYO this is adding cruft? We are discussing Deken dependencies and abs sharing. And also I`m following *your* good idea that a deken pkg must be “self operational”. Lets have the “normal ubuntu” users a more practical way of Pd while “super users” like you can do all the “$ sudo apt-get install pd-deken-apt” thing.

Mensaje telepatico asistido por maquinas.

Well my worries are this: I made a abs that uses [some~] which calls 3thpty pthread. I want the abs to be opened with all OS. I`m using Deken as source of [some~] so in my abs I [declare] a folder where I put: some~.dll pthread.dll some~.pd_darwin ? pthread ? some~.l_i386? pthread ? some~.pd_linux? pthread ? And there, just work. I know that I can do this with objects that DONT need pthread. How do I handle 3th pty Libs if those *are not* in the Deken Pkg?

Mensaje telepatico asistido por maquinas.

To: pd-list@lists.iem.at From: zmoelnig@iem.at Date: Wed, 20 Jul 2016 17:07:44 +0200 Subject: Re: [PD] Deken and Dependencies

On 07/20/2016 04:23 PM, Lucas Cordiviola wrote:

What will be the problem for a linux system to look for the 3th party Lib in the same folder as the ext (which needs it) if it can't find anywhere else in the local system?

IYO this is adding cruft?

yes.

We are discussing Deken dependencies and abs sharing.

thanks for the reminder :-)

And also I`m following *your* good idea that a deken pkg must be “self operational”.

yes.

Lets have the “normal ubuntu” users a more practical way of Pd while “super users” like you can do all the “$ sudo apt-get install pd-deken-apt” thing.

i think you misunderstood that (most likely because you are not using linux). the idea is, that anybody who installed "puredata" (the core Pd-vanilla package distributed on Debian and derivatives), also has "pd-deken-apt" installed (automatically). there is nothing "super user" to that.

gsmdr IOhannes

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

Thanx for clarifying.

there are three (3!) externals that require 3rdparty libraries.

There are (on linux) 3 Deken pkgs that are not “self operational”. This covers only past and near past. Solving those 3 cases does not solve near future Deken pkgs?

Mensaje telepatico asistido por maquinas.

To: pd-list@lists.iem.at From: zmoelnig@iem.at Date: Thu, 21 Jul 2016 04:58:29 +0200 Subject: Re: [PD] Deken and Dependencies

On 07/20/2016 05:45 PM, Lucas Cordiviola wrote:

I know that I can do this with objects that DONT need pthread.

pthread is available on every POSIX compliant system (linux and OSX). it's only W32 that makes the trouble.

really: looking at your list of missing W32-libraries and extrapolating it to the linux world, there are three (3!) externals that require 3rd party libraries. the problem is obviously much more prominent on W32, as the standard libraries available there collide with the way most externals are built (using mingw).

i think you are fighting to solve a marginal problem.

fgmsard IOhannes

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

On 2016-07-19 01:55, Lucas Cordiviola wrote:

What do you mean by “more secure”?, Deken packages have checksum.

the checksums are not used (yet). however, this is not what i meant. what i did mean is, that each and every DLL installed on your system is likely to have bugs and poses a security risk. on package-managed systems (such as most linux distributions), there are people who dedicate their time to make sure that any library installed on *your* system gets security fixes. this is something that cannot be expected by the pd externals maintainer.

tfgamsdr IOhannes