Après avoir découvert le dépôt cphub.net je me pose la question de la pertinence d'avoir deux repo distincts. Serait-il envisageable de mettre à dispo les spk de synocommunity sur cphub? Comme ca un seul gros dépôt pour toute la communauté syno. Qu'en pensez-vous, est-ce faisable?

Qu'est-ce qui n'est pas pertinent dans le fait d'avoir plusieurs dépôts ?

Community Package Hub (CPHub) fournit des paquets comme celui-ci qui ont posé beaucoup de problèmes (configuration Apache HS) aux utilisateurs. Malgré ça CBHub continue de le diffuser.

Il ne me semble donc pas pertinent de diffuser nos paquets avec ceux de CPHub (ou l'inverse) dans le sens où nous ne serons plus capables d'assurer la compatibilité de nos paquets avec ceux de CPhub.

Sans parler des downtime de cphub (genre 5 jours la ya 2 semaines ...)

Ok je ne savais pas pour les problèmes avec certains paquets. Mais un avoir un gros dépôt communautaire pour tous les utilisateurs de syno serait quand même un gros plus. Certains paquets de cphub sont intéressant. Le advanced power manager ou owncloud sont très intéressant et il est dommage de ne pas les trouver avec le reste des paquets synocommunity.

Tout package crée avec SPKSRC (propre, on va dire) peux être hébergé sur le repo de synocom

Je ne vois pas quel est le problème, tu peux ajouter ces deux dépôts dans le Centre de paquets.

Du coup tous les paquets de CPHub et SynoCommunity apparaissent bien dans le Centre de paquets.

Mais un avoir un gros dépôt communautaire pour tous les utilisateurs de syno serait quand même un gros plus.

Quel gros plus y aurait-il ?

D'un point de vue interopérabilité et maintenance ça devient un gros bordel.

[...] il est dommage de ne pas les trouver avec le reste des paquets synocommunity.

Je ne comprends pas ta remarque.

Tous les paquets de SynoCommunity sont open source et visible par tout le monde. Si tu veux, tu peux même cross-compiler un SPK existant toi même.

L'outil utilisé est spksrc, développé par superzebulon et moi même.

J'avais discuté avec CPHub avant qu'ils le mette en place, le problème est qu'ils ne s'assurent pas de la qualité des SPKs alors que moi je souhaite une bonne tracabilité, une ouverture du code (afin que quelqu'un d'autre prenne la maintenance d'un SPK si l'auteur ne la fait plus), et un framework utilisable par tous.

Deux idées, deux repos.

Oui ok je comprend mieux maintenant. Donc on peut très bien imaginer rajouter dans le spksrc advanced power management par exemple? Si quelqu'un s'en "occupe" bien entendu.

C'est ça ?

Si j'ai bien tout capté pour utiliser spksrc il faut obligatoirement linux, impossible de compiler sous windows?

Vouloir compiler du Linux sous Windows c'est comme boire une bière à l'aide d'une fourchette.

Tu peux très rester sous Widnows en utilisant un environnement virtuel (VirtualBox + Debian par exemple).

Ah yes une virtual box je n'y avais pas pensé à ca!

J'ai une VirtualBox pour spksrc avec son disque dur sur le Syno en iSCSI. Que je boot sur Windows 8 ou Ubuntu je peux lancer ma VM

Je vais tester ça, je suis vraiment noob en VM.

On peut rajouter n'importe quel SPK à spksrc à condition :

• D'en être l'auteur ou d'avoir l'autorisation d'en faire la copie sous la license de spksrc (BSD 3 clauses)
• Qu'il soit conforme aux autres SPKs, le plus simple est de copier des passages des scripts existants pour faire le sien

On peut rajouter n'importe quel SPK à spksrc à condition :

• D'en être l'auteur ou d'avoir l'autorisation d'en faire la copie sous la license de spksrc (BSD 3 clauses)

Un logiciel sous licence gpl ca ne passe pas?

Peu importe le logiciel sous-jacent, je parle là des scripts du package.

Ah oui ok, si je prend un logiciel sous gpl et que je créer moi même le script d'install puis je le push sur github c'est bon?

Oui

Tout package crée avec SPKSRC (propre, on va dire) peux être hébergé sur le repo de synocom

Hi,

this is Matthieu from the German Forum. I hope you don't mind me answering in English, but the bit of French I used to know is gone since quite some time.

Saying that packages from CPHub are in any way "unclean" isn't quite correct. We check every single package (both "by hand" and using automated systems). Just because we don't use your tool, doesn't mean they aren't of a good quality. By the way: We have a very long documentation to make sure everyone gets started the right way and knows how to work with spk-packages.

The discussion Diaoul is referring to was mostly about licenses, not about the tool in any way. They want everything to be completely open source. I respect that opinion, but don't share it. Not back then and not now. We already have packages that are "Freeware" (and will be forever). Its up to the developer to choose the license at CPH.

About the packages we share: The packages which require things like the "3rd party init" you are referring to exist since years, much longer than the system of package server exists. The developers gained lots and lots of experience conducting such mods and it has been used by thousands of users. It can very well be considered stable.

I know you don't care about interoperability (the message on your website has that pretty clear), but I do care. I do not just watch when users start loosing their data. When you published the package named "owncloud" a few days back, you didn't care about it. But it happened. The CPH-package of owncloud was already available for months and downloaded a lot. But because both upgrade-scripts work differently, data was lost when upgrading using your package.

I know you complained about such behaviour at Synologys side ...

Regarding the actual topic discussed here: There are no issues known to us when using both CPH and synocommunity-packages, except for the stated owncloud package.

@bud77: That downtime was about a month ago and lasted about 20hrs. The provider simply moved the server to another IP without notifying us. We have taken precautions now and are looking into further ones currently (like spreading basic functions to a failover server which will then ).

I hope we can do something about the issues stated. I already discussed some things with Synology and I am confident that I got the right contact this time so some things might actually change. As of now, consider renaming the owncloud-package for example.

Greetings,

Matthieu

Modifié le 13 août 201312 a par Matthieu-DS