[prev in list] [next in list] [prev in thread] [next in thread] 

List:       owncloud
Subject:    Re: [Owncloud] Removal of 3rd party libraries from the main repo
From:       Frank Karlitschek <karlitschek () kde ! org>
Date:       2012-02-19 18:35:04
Message-ID: BEBDEB95-E444-4301-B300-FAE3BAB41B05 () kde ! org
[Download RAW message or body]

Hi,

no one objected so I will implement it like this.

The 3rdparty folder will be automatically detected it it is in the owncloud=
 folder or in the parent folder. The location can also be set in the config=
.php
As a developer you have the checkout the 3rdpart repository in parallel to =
the owncloud repo and it works automatically.

I will do the same for the apps folder as discussed earlier.


I hope thats now O.K. for everybody :-)



Cheers
Frank




On 16.02.2012, at 13:19, Frank Karlitschek <karlitschek@kde.org> wrote:

> =

> On 16.02.2012, at 12:33, Jakob Sack wrote:
> =

>> 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-3rd=
party"
>> 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 defa=
ult config.php to the changes
>> =

> =

> I think this makes a lot of sense.
> =

> =

>> The only disadvantage I can see right now is that the 3dparty repository=
 still will be a big mess with hundreds of licenses.
> =

> I think thats not a big problem because we don=B4t modify the 3rd party s=
tuff. It=B4s just a collection of external libraries. =

> I=B4m fine as long as the ownCloud repo is clean :-)
> =

> =

>> What do you think?
> =

> +1
> =

>> Regards,
>> =

>> Jakob
> =

> Frank
> =

> =

>> 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 i=
s: "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
>>> karlitschek@kde.org
>>> =

>>> =

>>> _______________________________________________
>>> Owncloud mailing list
>>> Owncloud@kde.org
>>> https://mail.kde.org/mailman/listinfo/owncloud
>> =

>> _______________________________________________
>> Owncloud mailing list
>> Owncloud@kde.org
>> https://mail.kde.org/mailman/listinfo/owncloud
> =

> Frank Karlitschek
> karlitschek@kde.org
> =

> =

> _______________________________________________
> Owncloud mailing list
> Owncloud@kde.org
> https://mail.kde.org/mailman/listinfo/owncloud

Frank Karlitschek
karlitschek@kde.org


_______________________________________________
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud
[prev in list] [next in list] [prev in thread] [next in thread]