[Pkg-tigervnc-devel] Request to Join Project TigerVNC package for Debian from Ola Lundqvist (opal)

[Yaroslav Halchenko]

On Tue, 26 Jan 2016, Ola Lundqvist wrote:

>    Hi
>    I have now pushed my changes that we discussed before. I have not started
>    to join anything yet.
>    I think the vncconfig and vncpasswd commands are common for extension and
>    standalone server so if we do not join the extension and the standalone we
>    need to keep the common package separately.
>    I do not think we should enable vnc automatically without a question on it
>    first, A since it is a policy violation to do so (edit some other
>    configuration file). I see the RC bugs already now :-). This may be a
>    security problem too. However when investigating it a little more I see
>    that we can enable it automatically. See in the bottom of the mail.
>    If we have a debconf question to enable it I do not see a problem to
>    include it in the same package as the standalone anyway.
>    However based on my experience on creating packages with debconf questions
>    on enabling stuff I do not think it is worth the trouble. There are number
>    of problematic scenarios that we have to consider namely:
>    1) Extension is first installed, someone edit the X config file to remove
>    tigervnc and then the package is upgraded. It must not be enabled again
>    then.
>    2) Extension is first installed, someone edit the X config file to remove
>    tigervnc and then remove extension and install it again. Now it shall only
>    be enabled if the question is asked...
>    3) Extension is installed, removed and re-installed with a no to the
>    question. Shall it be disabled then?
>    Well there are more problematic scenarios. I do not say it is impossible.
>    I just say that this kind of automatic additions are quite cumbersome to
>    make working.
>    There is a reason why a something.d directory structure has been created
>    for many packages.
>    Hmm it looks like we have that for xserver too. :-) I was not aware of
>    that.
>    We can make a file inA /usr/share/X11/xorg.conf.d/. That is probably the
>    easiest.

that is exactly along the lines I thought on this too ;)

>    And this way it is still up to the admin to do the change (copy the files
>    to /etc/xorg.conf.d)

or done by debconf script

indeed it is all hypothetical  etc ATM but better to keep it as an
available enhancement in the future

> . This way we should be able to merge also the
>    extensio too.
>    As you see I write a lot of should, meaning that I think this is how it
>    would work, but I'm not sure and therefore I want you to think a little
>    before accepting my statements. :-)
>    Cheers
>    // Ola
>    On Tue, Jan 26, 2016 at 8:58 PM, Yaroslav Halchenko
>    <debian at onerussian.com> wrote:

>      On Tue, 26 Jan 2016, Ola Lundqvist wrote:

>      >A  A  Hi Yaroslav
>      >A  A  I do not mind pushing the changes directly, but I thought you may
>      want to
>      >A  A  check things before as this was the first thing I did in this
>      project.
>      >A  A  Will push now.
>      >A  A  I think both server packages can make use of the -common package.
>      >A  A  Here I have a thought, why do we have separate server packages? I
>      know the
>      >A  A  FTP masters do not want unnecessary split of the packages. Is
>      there any
>      >A  A  specific reason why we have different pages for the scraping
>      server, the
>      >A  A  normal server and the library?
>      >A  A  Just checking what your thoughts were regarding this.
>      >A  A  Some facts:
>      >A  A  - common ~60 KB
>      >A  A  - scraping ~180 KB
>      >A  A  - standalone ~1.1 MB
>      >A  A  - xorg extension ~200 KB
>      >A  A  The dependencies are quite similar too. The main difference is
>      that the
>      >A  A  extension do not need perl dependencies.
>      >A  A  My suggestion is that we merge them together, but I do not want
>      to do that
>      >A  A  without your (common) approval :-)

>      I don't mind... unless someone sees some side-effect e.g. for xorg
>      extensionA  - may be for xorg extension we could eventually provide
>      somehow configuration/debconf to enable it automagically when package
>      gets installed?A  So I would vote to join scraping + standalone but may
>      be leave xorg extension separately?A  if for extension we don't need
>      anything of common -- we better suck common into the tightervnc-server
>      package providing both scraping + standalone.A  So 2 pages instead of 4?
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik