guacamole-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Jumper (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GUACAMOLE-98) Building Guacamole bundle for Univention UCS 4.x
Date Tue, 30 Aug 2016 17:40:20 GMT

    [ https://issues.apache.org/jira/browse/GUACAMOLE-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15449631#comment-15449631
] 

Michael Jumper commented on GUACAMOLE-98:
-----------------------------------------

{quote}
OMG ! Guacamole is awesome 
{quote}

Thanks!

{quote}
In Univention, it's up to the editor of the App to purpose and upload their bundled app, before
a Univention Team's check and tests and then distribute it.
Today, I've to integrate Guacamole with Univention which allow us to manage LDAP tree. To
make this fully compatible, over update, and to ease of deploy, I'm creating an installer
which uses the guacamole docker image and sets several config files.
{quote}

I'm pleased that your first thought was to contribute to the upstream project directly, but
I think the proper home for third-party Guacamole packaging is downstream (within that third-party).
In this case, you would be the downstream package maintainer of the Univention package.

Consider the packaging of various software projects in Debian, Ubuntu, Fedora, etc. There
are numerous Linux distributions, each with their own packaging needs and repositories, as
well as systems such as yours. If the upstream projects all served as the homes for their
respective packages, it would be a complete mess. The usual methodology is:

# The upstream project maintains itself and worries strictly about providing reliable source
code, writing the canonical documentation, and working together with the community.
# Downstream projects (such as Debian, Ubuntu, or in your case Univention) consume the project,
producing packages that make it easier for their users to use that software.

{quote}
... providing a little peace of work to you awesome project without breaking any property
right to the ASF or the project's team. It's my first time wanted to join a such process and
I don't want to do 'newbie' mistakes.
{quote}

Definitely understood. Again, as long as you adhere to the Apache license and don't violate
trademarks then you don't need to worry. If you encounter issues as you attempt to package
Guacamole for your platform, post in an appropriate mailing list (guacamole.incubator.apache.org/support/#mailing-lists)
and we'll gladly help.

The key point here is that system-specific packages of a project do not need to be part of
that project. It's important that they exist, and that they be provided to the community,
it's usually better that they are maintained separately.

Does that make sense?

> Building Guacamole bundle for Univention UCS 4.x
> ------------------------------------------------
>
>                 Key: GUACAMOLE-98
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-98
>             Project: Guacamole
>          Issue Type: New Feature
>          Components: guacamole
>         Environment: UCS 4.1-2 (Debian 8)
> UCS 4.1-3 (Debian 8)
>            Reporter: Valentin BRICE
>            Priority: Minor
>
> Building Guacamole bundle for Univention UCS 4.x
> UCS is an open source Active Directory alternative solution build on top of Debian and
OpenLDAP. It implements many features of MS - AD as kerberos auth, Users policies, etc ...
> The purpose is to create a bundled install process for Guacamole under Univention App
Center powered by Docker container system, to install, configure and managed guacGroupConfig
under Univention Management Console
> For documentation : 
>                  https://docs.software-univention.de/app-tutorial-4.0.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message