Hi,
I suggest the following solution:
- create a repository for 3dparty resources, called "owncloud-3dparty"
- add the 3dparty-folder to the load path:
a) If defined in config.php then use this path
b) look for 3dparty in base directory
c) look for "owncloud-3dparty" in parent directory
d) die if the 3dparty-folder is not found
I think that this is a good approach because:
1) ownCloud and 3dparty are not in one repository
2) ownCloud will run after "git clone owncloud && git clone
owncloud-3rdparty"
3) ownCloud runs if you copy/symlink the 3dparty folder to the base
path
4) distributions can put the 3dparty stuff everywhere and adapt the
default config.php to the changes
The only disadvantage I can see right now is that the 3dparty
repository still will be a big mess with hundreds of licenses.
What do you think?
Regards,
Jakob
Am 16.02.2012 10:53, schrieb Frank Karlitschek:
On 16.02.2012, at 10:36, Klaas Freitag wrote:
On 16.02.2012 10:31, Frank Karlitschek wrote:
Next time more feedback to the proposed change on the mailinglist
is appreciated ;-)
Point taken, sorry.
:-)
Although, I tink I somewhere replied with my core opinion here which
is: "3rdparty should go away." ;-)
Thats the best approach.
But this would be even more difficult for developers. The idea of the
3rdparty repo was to have a place where all the right versions of the
external libs are collected. The user just has to copy it into
3rdparty and it works.
All a developer has to do is to clone the 3rdparty repo as git
submodule into the 3rdparty folder and it should work as before.
Maintaining everything in one big repository with incompatible
licenses is not a solution in the long run IMHO.
Opinions?
Frank
Frank Karlitschek
[email protected]
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
