www.cendio.com
Bug 5828 - Debian and Ubuntu have officialy abandoned LSB
: Debian and Ubuntu have officialy abandoned LSB
Status: CLOSED FIXED
: ThinLinc
Server OS
: pre-1.0
: PC Unknown
: P2 Normal
: 4.7.0
Assigned To:
:
:
: 5974
: 5829
  Show dependency treegraph
 
Reported: 2016-04-01 14:46 by
Modified: 2016-12-05 15:06 (History)


Attachments
check_lsb_5.0.py (1.70 KB, text/plain)
2016-08-17 16:23, Peter Åstrand
Details
check_lsb_4.1.py (488 bytes, text/x-python)
2016-08-30 14:09, Peter Åstrand
Details
libs-to-packages (2.24 KB, application/octet-stream)
2016-08-30 14:35, Peter Åstrand
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2016-04-01 14:46:03
So Debian has official abandoned LSB and have dropped the 'lsb' package that
pulls in the necessary dependencies. Ubuntu has simply followed upstream and
16.04 therefore no longer has any meta package to get the necessary packages.

(for extra fun there is also some bug in Ubuntu that pulls in cups-filters-lsb
when you ask for "lsb")
------- Comment #1 From cendio 2016-04-01 14:46:40 -------
Debian discussion thread:

https://lists.debian.org/debian-lsb/2015/07/msg00000.html
------- Comment #2 From cendio 2016-04-04 09:27:49 -------
https://lwn.net/Articles/658809/
------- Comment #3 From cendio 2016-04-11 12:58:28 -------
See also Bug 5405. I guess we need to do the same for Debian/Ubuntu?
------- Comment #4 From cendio 2016-06-30 13:23:49 -------
We've discussed several ways we could approach this. We started by looking at
why we have the LSB requirement and what our needs are:

 1. What libraries and binaries can we assume exist on the system? What do we
need to ship/link statically ourselves?

 2. How does a ThinLinc developer know what libraries/functions/binaries are
safe to use, and which require new packaging?

 3. How to we communicate our requirements in a clear manner to our customers?

 (4. Where should files be located? (FHS))

We also discussed that no matter the solution, there could be value in
clarifying the requirements in terms of which of the popular distributions
fulfill the requirements.

When we discussed solutions, there were two main themes that could be seen:

 a) Make the requirements a bit more fuzzy. E.g. refer to specific
distributions rather than specific technical requirements.

 b) Take over the burden of specification to ourselves, essentially copying
relevant portions of LSB to our documentation/product.

Some more tangible suggestions we discussed:

 1. Only support a few specific distributions (essentially just the recommended
ones), and keep track of what they contain. We also had a slightly softer
approach where these where reference platforms that bugs would need to be
replicated on for us to care.

 2. Have an explicit list of dependencies, somewhat copying the work from LSB
in to our own documentation.

 3. No documented requirements and just try to have a feel for what libraries
are "always present".

 4. Enforce the LSB requirement harder and drop support for non-LSB
distributions. In practice this would probably limit us to the Red Hat sphere.

 5. Continue referring to LSB, but in a softer way. Essentially just turning it
in to an externally composed list of libraries, rather than some form of
certification and compliance issue. This would mean we would stop using
LSB-specific stuff but still use the "normal" portions of LSB.

We decided to explore the last alternative. The obvious steps so far would be
to find a good description for the documentation, and update tl-setup to be
more explicit about what libraries are needed rather than lsb meta packages.

Two important questions arose as part of this:

 - Can we rely on just the core part of LSB, or do we need to drag along more
LSB modules?

 - Can we restrict ourselves to just libraries specified by LSB and solve the
issue of necessary commands some other way?
------- Comment #5 From cendio 2016-06-30 13:40:46 -------
(In reply to comment #0)
> (for extra fun there is also some bug in Ubuntu that pulls in cups-filters-lsb
> when you ask for "lsb")

This bug has now been fixed in Ubuntu. They've also done even more cleanup of
LSB stuff so install_initd is no longer being shipped.
------- Comment #6 From cendio 2016-08-17 16:23:23 -------
Created an attachment (id=731) [details]
check_lsb_5.0.py

The attached Python program can be used to verify if LSB 5.0 libs are present.
The result is that the full LSB 5.0 is too new. Things are missing even on,
say, CentOS6:

$ ./check_lsb_5.0.py 
ERROR: ld.so: object 'libcairo-gobject.so.2' from LD_PRELOAD cannot be
preloaded: ignored.
ERROR: ld.so: object 'libcairo-script-interpreter.so.2' from LD_PRELOAD cannot
be preloaded: ignored.
ERROR: ld.so: object 'libtiff.so.5' from LD_PRELOAD cannot be preloaded:
ignored.

Also, LSB 5 "is the first major release to break 100% compatibility with
earlier versions."
(https://wiki.linuxfoundation.org/en/ReleaseNotes50#LSB_5.0_Release_Notes)

Therefore, I think we should try an earlier version instead, such as 4.1.
------- Comment #9 From cendio 2016-08-25 18:04:27 -------
Ubuntu re-added the LSB package to 16.04 on 2016-06-23, moving it into
xenial-updates on 2016-07-01 after verification.

https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1536353/comments/69
https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1536353/comments/82

The reason behind re-adding LSB support is printer drivers that has
dependencies on LSB.

https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1536353
------- Comment #12 From cendio 2016-08-29 13:57:09 -------
(In reply to comment #6)

> Therefore, I think we should try an earlier version instead, such as 4.1.

LSB 4.1.0 looks like a good candidate. It contains several sections:

LSB 4.1 Core Specification
LSB 4.1 C++ Specification
LSB 4.1 Desktop Specification
LSB 4.1 Languages Specification
LSB 4.1 Printing Specification
(Optional) LSB 4.1 Trial Use Specification

Wrt libs and programs, let's go into the details, backwards:

Trial Use
----------
Empty


Printing
--------
Provides:
libcups.so.2
libcupsimage.so.2

...but we are not using any of these. Also provides "gs". Note that we are
currently requiring a ps2pdf binary, and at least on CentOS this is a thin
wrapper around "gs". In other words, if we start depending on "gs" instead, we
could replace our ps2pdf requirement with "gs" which is in LSB 4.1 Printing.
But that's probably another bug.


Languages
---------
No libraries. Provides Python and Perl. A little bit unclear about Python 2 vs
Python 3. Probably another bug.


Desktop
--------
This specification contains a long list of Libraries (which sometimes also
includes commands), plus xdg-utils. In our case, we can either check for all
libraries (maybe except QT), or use a subset, which can even be just "libX11". 


Core
-----
This is the most important specification. I believe we can and should depend on
everything except "ld-lsb.so". 


In principle, we could consider LSB 4.0 instead of 4.1. That would better match
the common distributions that are certified. For example, RHEL5 and RHEL6 are
only certified for LSB 4.0, see:
https://www.linuxbase.org/lsb-cert/productdir.php?by_lsb . On the other hand,
the changes between 4.0 and 4.1 are small, so I'd say that we should go for 4.1
unless we stumble upon some problems. That means that we will depend on a
slightly more modern base.
------- Comment #13 From cendio 2016-08-29 14:23:00 -------
When it comes to extracting the libs and commands from the specifications, I've
tried several alternatives. No perfect solution yet - the specifications are
not fully consistent. For example, these two solutions produces different
results:

awk '/Runtime Name/{f=1;next} /^$/{f=0} f' | grep -v "See arch" | sort | uniq |
awk 'BEGIN {printf "["} {printf "\"" $2 "\", "} END {print "]"}'

awk '/SONAME:/{print $2}' | grep -v ^See | sort | uniq | awk 'BEGIN {printf
"["} {printf "\"" $1 "\", "} END {print "]"}'

The former solution gives a list without "libssl3.so", since they have
forgotten to add libssl to the "overview" table in Table 3-1. On the other
hand, with the latter solution, ld-lsb.so.3 is missed, because they have
forgotten to add a SONAME: tag for it... 

Another solution would be to use the LSB "SpecDB". It is available via
Mercurial, and for example contains:

./ArchLib.init:INSERT INTO `ArchLib` VALUES (278,1,'libssl3.so','4.0',NULL);

But I've not done any more work on that. 

Using the SONAME solution, we get this wrt libraries:

LSB-Core-generic:
["libcrypt.so.1", "libdl.so.2", "libgcc_s.so.1", "libncurses.so.5",
"libnspr4.so", "libnss3.so", "libpam.so.0", "libpthread.so.0", "librt.so.1",
"libssl3.so", "libutil.so.1", "libz.so.1", ]

LSB-Core-IA32 / LSB-Core-AMD64:
["libcrypt.so.1", "libc.so.6", "libdl.so.2", "libgcc_s.so.1", "libm.so.6",
"libncurses.so.5", "libpthread.so.0", "libutil.so.1", "libz.so.1", ]

Combined LSB-Core:

["libcrypt.so.1", "libc.so.6", "libdl.so.2", "libgcc_s.so.1", "libm.so.6",
"libncurses.so.5", "libnspr4.so", "libnss3.so", "libpam.so.0",
"libpthread.so.0", "librt.so.1", "libssl3.so", "libutil.so.1", "libz.so.1", ]


Wrt "Desktop", this is what we get:

$ cat LSB-Desktop-generic.txt LSB-Desktop-IA32.txt | ./lsblibs-to-pylist
["libasound.so.2", "libatk-1.0.so.0", "libcairo.so.2", "libfontconfig.so.1",
"libfreetype.so.6", "libgdk_pixbuf-2.0.so.0", "libgdk_pixbuf_xlib-2.0.so.0",
"libgdk-x11-2.0.so.0", "libglib-2.0.so.0", "libGL.so.1", "libGLU.so.1",
"libgmodule-2.0.so.0", "libgobject-2.0.so.0", "libgthread-2.0.so.0",
"libgtk-x11-2.0.so.0", "libICE.so.6", "libjpeg.so.62", "libpango-1.0.so.0",
"libpangocairo-1.0.so.0", "libpangoft2-1.0.so.0", "libpangoxft-1.0.so.0",
"libpng12.so.0", "libQtCore.so.4", "libQtGui.so.4", "libqt-mt.so.3",
"libQtNetwork.so.4", "libQtOpenGL.so.4", "libQtSql.so.4", "libQtSvg.so.4",
"libQtXml.so.4", "libSM.so.6", "libX11.so.6", "libXext.so.6", "libXft.so.2",
"libXi.so.6", "libxml2.so.2", "libXrender.so.1", "libXt.so.6", "libXtst.so.6",
]

But my suggestion is that we start with just "libX11". This will give us a
combined list of:


["libcrypt.so.1", "libc.so.6", "libdl.so.2", "libgcc_s.so.1", "libm.so.6",
"libncurses.so.5", "libnspr4.so", "libnss3.so", "libpam.so.0",
"libpthread.so.0", "librt.so.1", "libssl3.so", "libutil.so.1", "libz.so.1",
"libX11.so.6"]
------- Comment #14 From cendio 2016-08-30 14:09:16 -------
Created an attachment (id=735) [details]
check_lsb_4.1.py

New script to check for LSB 4.1 libs (Combined Core list plus libX11).
------- Comment #15 From cendio 2016-08-30 14:35:25 -------
Created an attachment (id=736) [details]
libs-to-packages

The attached script generates a mapping between required libraries and the
package providing this library. Requires dpkg-query or rpm.
------- Comment #16 From cendio 2016-08-30 14:36:26 -------
(In reply to comment #15)
> Created an attachment (id=736) [details] [details]
> libs-to-packages
> 
> The attached script generates a mapping between required libraries and the
> package providing this library. Requires dpkg-query or rpm.

Results from running this script on different platforms:


RHEL
5:
{'libX11.so.6': 'libX11',
 'libc.so.6': 'glibc',
 'libcrypt.so.1': 'glibc',
 'libdl.so.2': 'glibc',
 'libgcc_s.so.1': 'libgcc',
 'libm.so.6': 'glibc',
 'libncurses.so.5': 'ncurses',
 'libnspr4.so': 'nspr',
 'libnss3.so': 'nss',
 'libpam.so.0': 'pam',
 'libpthread.so.0': 'glibc',
 'librt.so.1': 'glibc',
 'libssl3.so': 'nss',
 'libutil.so.1': 'glibc',
 'libz.so.1': 'zlib'}

6:
{'libX11.so.6': 'libX11',
 'libc.so.6': 'glibc',
 'libcrypt.so.1': 'glibc',
 'libdl.so.2': 'glibc',
 'libgcc_s.so.1': 'libgcc',
 'libm.so.6': 'glibc',
 'libncurses.so.5': 'ncurses-libs',
 'libnspr4.so': 'nspr',
 'libnss3.so': 'nss',
 'libpam.so.0': 'pam',
 'libpthread.so.0': 'glibc',
 'librt.so.1': 'glibc',
 'libssl3.so': 'nss',
 'libutil.so.1': 'glibc',
 'libz.so.1': 'zlib'}

- 'libncurses.so.5': 'ncurses',
+ 'libncurses.so.5': 'ncurses-libs',


7:
{'libX11.so.6': 'libX11',
 'libc.so.6': 'glibc',
 'libcrypt.so.1': 'glibc',
 'libdl.so.2': 'glibc',
 'libgcc_s.so.1': 'libgcc',
 'libm.so.6': 'glibc',
 'libncurses.so.5': 'ncurses-libs',
 'libnspr4.so': 'nspr',
 'libnss3.so': 'nss',
 'libpam.so.0': 'pam',
 'libpthread.so.0': 'glibc',
 'librt.so.1': 'glibc',
 'libssl3.so': 'nss',
 'libutil.so.1': 'glibc',
 'libz.so.1': 'zlib'}

No diff.


SLES12
{'libX11.so.6': 'libX11-6',
 'libc.so.6': 'glibc',
 'libcrypt.so.1': 'glibc',
 'libdl.so.2': 'glibc',
 'libgcc_s.so.1': 'libgcc_s1',
 'libm.so.6': 'glibc',
 'libncurses.so.5': 'libncurses5',
 'libnspr4.so': 'mozilla-nspr',
 'libnss3.so': 'mozilla-nss',
 'libpam.so.0': 'pam',
 'libpthread.so.0': 'glibc',
 'librt.so.1': 'glibc',
 'libssl3.so': 'mozilla-nss',
 'libutil.so.1': 'glibc',
 'libz.so.1': 'libz1'}


Ubuntu
14.04:
{'libX11.so.6': 'libx11-6',
 'libc.so.6': 'libc6',
 'libcrypt.so.1': 'libc6',
 'libdl.so.2': 'libc6',
 'libgcc_s.so.1': 'libgcc1',
 'libm.so.6': 'libc6',
 'libncurses.so.5': 'libncurses5',
 'libnspr4.so': 'libnspr4',
 'libnss3.so': 'libnss3',
 'libpam.so.0': 'libpam0g',
 'libpthread.so.0': 'libc6',
 'librt.so.1': 'libc6',
 'libssl3.so': 'libnss3',
 'libutil.so.1': 'libc6',
 'libz.so.1': 'zlib1g'}


16.04:
{'libX11.so.6': 'libx11-6',
 'libc.so.6': 'libc6',
 'libcrypt.so.1': 'libc6',
 'libdl.so.2': 'libc6',
 'libgcc_s.so.1': 'libgcc1',
 'libm.so.6': 'libc6',
 'libncurses.so.5': 'libncurses5',
 'libnspr4.so': 'libnspr4',
 'libnss3.so': 'libnss3',
 'libpam.so.0': 'libpam0g',
 'libpthread.so.0': 'libc6',
 'librt.so.1': 'libc6',
 'libssl3.so': 'libnss3',
 'libutil.so.1': 'libc6',
 'libz.so.1': 'zlib1g'}

No diff.


Fedora 23:
{'libX11.so.6': 'libX11',
 'libc.so.6': 'glibc',
 'libcrypt.so.1': 'glibc',
 'libdl.so.2': 'glibc',
 'libgcc_s.so.1': 'libgcc',
 'libm.so.6': 'glibc',
 'libncurses.so.5': 'ncurses-libs',
 'libnspr4.so': 'nspr',
 'libnss3.so': 'nss',
 'libpam.so.0': 'pam',
 'libpthread.so.0': 'glibc',
 'librt.so.1': 'glibc',
 'libssl3.so': 'nss',
 'libutil.so.1': 'glibc',
 'libz.so.1': 'zlib'}
------- Comment #17 From cendio 2016-08-31 08:57:20 -------
(In reply to comment #16)

> 
> RHEL
> 5:
> {'libX11.so.6': 'libX11',
>  'libc.so.6': 'glibc',
>  'libcrypt.so.1': 'glibc',
>  'libdl.so.2': 'glibc',
>  'libgcc_s.so.1': 'libgcc',
>  'libm.so.6': 'glibc',
>  'libncurses.so.5': 'ncurses',
>  'libnspr4.so': 'nspr',
>  'libnss3.so': 'nss',
>  'libpam.so.0': 'pam',
>  'libpthread.so.0': 'glibc',
>  'librt.so.1': 'glibc',
>  'libssl3.so': 'nss',
>  'libutil.so.1': 'glibc',
>  'libz.so.1': 'zlib'}
> 
> 6:
> {'libX11.so.6': 'libX11',
>  'libc.so.6': 'glibc',
>  'libcrypt.so.1': 'glibc',
>  'libdl.so.2': 'glibc',
>  'libgcc_s.so.1': 'libgcc',
>  'libm.so.6': 'glibc',
>  'libncurses.so.5': 'ncurses-libs',
>  'libnspr4.so': 'nspr',
>  'libnss3.so': 'nss',
>  'libpam.so.0': 'pam',
>  'libpthread.so.0': 'glibc',
>  'librt.so.1': 'glibc',
>  'libssl3.so': 'nss',
>  'libutil.so.1': 'glibc',
>  'libz.so.1': 'zlib'}
> 
> - 'libncurses.so.5': 'ncurses',
> + 'libncurses.so.5': 'ncurses-libs',

If we want to support RHEL5, we need to handle this difference. The available
ncurses packages (not including development/debug packages) on each version
are:

5:
ncurses

6,7:
ncurses
ncurses-base
ncurses-libs
ncurses-static
ncurses-term

On 6,7, the ncurses package requires ncurses-libs. In other words, we should
depend on the "ncurses" package, ie use the RHEL5 list.
------- Comment #20 From cendio 2016-08-31 17:04:54 -------
(In reply to comment #16)
> (In reply to comment #15)
> > Created an attachment (id=736) [details] [details] [details]
> > libs-to-packages
> > 
> > The attached script generates a mapping between required libraries and the
> > package providing this library. Requires dpkg-query or rpm.
> 
> Results from running this script on different platforms:
> 
> 
> RHEL
> 5:
> {'libX11.so.6': 'libX11',
>  'libc.so.6': 'glibc',
>  'libcrypt.so.1': 'glibc',
>  'libdl.so.2': 'glibc',
>  'libgcc_s.so.1': 'libgcc',
>  'libm.so.6': 'glibc',
>  'libncurses.so.5': 'ncurses',
>  'libnspr4.so': 'nspr',
>  'libnss3.so': 'nss',
>  'libpam.so.0': 'pam',
>  'libpthread.so.0': 'glibc',
>  'librt.so.1': 'glibc',
>  'libssl3.so': 'nss',
>  'libutil.so.1': 'glibc',
>  'libz.so.1': 'zlib'}

Tested that these packages are sufficient for ThinLinc, using the various RHEL
versions:

RHEL 5.10 Server Minimal
RHEL 6.5 Server Minimal
RHEL 7.0 Server Minimal

Version 5 worked fine. However, with 6 and 7 the welcome dialog was garbled due
to some kind of font problem. On at least RHEL6, the problem goes away after
installing the "lsb" package, which installs an additional 83 packages. In
other words, the current list is not enough to get a ThinLinc system that works
(good).
------- Comment #21 From cendio 2016-09-01 12:43:50 -------
See also: Bug 5974.
------- Comment #22 From cendio 2016-09-06 14:27:36 -------
(In reply to comment #20)

> RHEL 5.10 Server Minimal
> RHEL 6.5 Server Minimal
> RHEL 7.0 Server Minimal
> 
> Version 5 worked fine. However, with 6 and 7 the welcome dialog was garbled due
> to some kind of font problem. On at least RHEL6, the problem goes away after
> installing the "lsb" package, which installs an additional 83 packages. In
> other words, the current list is not enough to get a ThinLinc system that works
> (good).

Now investigated. The problem goes away if I'm installing either urw-fonts or
xorg-x11-fonts-Type1. By installing lsb, the ghostscript package is also
installed, which pulls in urw-fonts. Our options are:

1) do nothing

2) Directly install urw-fonts

3) Install urw-fonts by installing ghostscript - check for "gs" binary, which
LSB requires

4) Install ghostscript by checking for libgs.so.9 or similar (not in LSB).

5) Directly install xorg-x11-fonts-Type1. 

6) Modify our PyGTK stuff to not require any additional fonts, perhaps by
shipping a fallback font


My preference right now is option 3):

We need ghostscript anyway for a working printer support. As pointer our on
comment #12, we could also get rid of our manual check for ps2pdf if we ship
the ps2pdf wrapper ourselves instead.

One drawback though is that the LSB module currently has no support for
checking LSB commands - only libs. 

Will check other distros before making a decision.
------- Comment #23 From cendio 2016-09-07 15:35:02 -------
(In reply to comment #22)
 7.0 Server Minimal
> > 
> > Version 5 worked fine. However, with 6 and 7 the welcome dialog was garbled due
> > to some kind of font problem. On at least RHEL6, the problem goes away after
> > installing the "lsb" package, which installs an additional 83 packages. In
> > other words, the current list is not enough to get a ThinLinc system that works
> > (good).
> 
> Now investigated. The problem goes away if I'm installing either urw-fonts or
> xorg-x11-fonts-Type1. By installing lsb, the ghostscript package is also
> installed, which pulls in urw-fonts. Our options are:
> 
> 1) do nothing
> 
> 2) Directly install urw-fonts
> 
> 3) Install urw-fonts by installing ghostscript - check for "gs" binary, which
> LSB requires
> 
> 4) Install ghostscript by checking for libgs.so.9 or similar (not in LSB).
> 
> 5) Directly install xorg-x11-fonts-Type1. 
> 
> 6) Modify our PyGTK stuff to not require any additional fonts, perhaps by
> shipping a fallback font
> 
> 
> My preference right now is option 3):
> 
> We need ghostscript anyway for a working printer support. As pointer our on
> comment #12, we could also get rid of our manual check for ps2pdf if we ship
> the ps2pdf wrapper ourselves instead.
> 
> One drawback though is that the LSB module currently has no support for
> checking LSB commands - only libs. 
> 
> Will check other distros before making a decision.

I've tested on minimal SLES12SP1 and Ubuntu 16.04 now. The font problem is not
present on those. RHEL needs to be handled anyway though. My suggestion is to
use solution 3):

Define the "gs" binary as an essential and required command. As earlier stated,
it's in LSB. Patch essentials.py:

--- modules/thinlinc/tlsetup/essential.py       (revision 31673)
+++ modules/thinlinc/tlsetup/essential.py       (arbetskopia)
@@ -24,7 +24,7 @@
 essential_optional = False
 essential_title_msg = "Essential Commands"

-essential_commands = ["netstat", "pgrep", "xauth"]
+essential_commands = ["netstat", "pgrep", "xauth", "gs"]
 joined_commands = ", ".join(essential_commands[:-1]) + ", and " +
essential_commands[-1]

 essential_base_msg = """ThinLinc requires a few essentials commands: \
@@ -61,6 +61,9 @@
         logging.warning("No information about which package provides xauth on
this distribution")
         return None

+    # gs
+    backend.add_package_by_name("ghostscript")
+


Then, create a new bug for shipping ps2pdf ourselves and remove that check from
printer.py; to be fixed later.
------- Comment #24 From cendio 2016-09-08 15:09:30 -------
ncurses is causing some more problems. Fedora is on libncurses.so.6, so
libncurses.so.5 is in ncurses-compat-libs.
------- Comment #25 From cendio 2016-09-09 11:12:32 -------
The error message when packages cannot be installed automatically could be more
helpful. Right now we dump the entire list of dependencies. However we know
which libraries are missing, so we should limit the list to just those.
------- Comment #27 From cendio 2016-09-12 10:43:00 -------
(In reply to comment #24)
> ncurses is causing some more problems. Fedora is on libncurses.so.6, so
> libncurses.so.5 is in ncurses-compat-libs.

Fixed. 

(In reply to comment #25)
> The error message when packages cannot be installed automatically could be more
> helpful. Right now we dump the entire list of dependencies. However we know
> which libraries are missing, so we should limit the list to just those.

Not a new problem; this is how it works for essentials.py also. Not possible to
implement due to bug 5985.
------- Comment #29 From cendio 2016-09-12 14:15:49 -------
I've tested r31698 (own build) on minimal installations of:

RHEL 5.10 (did setenfoce 0 after installation due to known bug)
RHEL 6
RHEL 7
Ubuntu 16.04
SLES12SP1

In installer/tl-setup, I've used the default option on every prompt. This
resulted in a working ThinLinc installation on all platforms.
------- Comment #30 From cendio 2016-09-13 15:33:29 -------
Installation of postfix "hangs" package installation for ~5 minutes on debian
based system, seen on both elementary and ubuntu server.
------- Comment #32 From cendio 2016-09-14 13:42:20 -------
Tested lsb installation for following distributions:

  - debian 8
  - fedora server 24
  - ubuntu server 16.04
  - centos 6.8 minimal
  - elementary os - loki

where those above distributions without graphical console (Xorg), required
xlibs / xauth are installed. When installing additional xterm and enabled xterm
profile in ThinLinc configuration, a session was created successfully.

debian based distributions which didn't have postfix installed suffered from
the interactive installation problem. which will be retested with fix in
comment #31.
------- Comment #34 From cendio 2016-09-14 17:01:01 -------
Works as expected.
------- Comment #35 From cendio 2016-09-16 09:42:15 -------
tl-setup wants to install postfix even though I have a sendmail in PATH on
Fedora 24.

> $ which sendmail
> /usr/sbin/sendmail
------- Comment #36 From cendio 2016-09-19 10:48:40 -------
The current code doesn't look like it will do the correct thing if
DISTRIBUTION_FAMILY is set to something unknown. I think we need to have a
different layout for the data structures.
------- Comment #41 From cendio 2016-09-19 14:53:22 -------
Should be fixed now. Tester needs to make sure that virtual packages are
handled properly. I.e. test both when no package is installed, and when a
non-default one is installed (by default we mean the one tl-setup would pick).
------- Comment #42 From cendio 2016-09-20 11:17:55 -------
*** Bug 5994 has been marked as a duplicate of this bug. ***
------- Comment #45 From cendio 2016-09-23 13:12:50 -------
We have decided to test tl-setup on the following platforms:

* RHEL5
* RHEL7
* Ubuntu 16.04-desktop
* Debian 8
* SLES11 sp3
* SLES12 sp1
* Fedora 24
* One other distribution which falls outside of our "distribution families",
for example Gentoo
------- Comment #46 From cendio 2016-09-26 13:31:11 -------
Successfully tested on:

✓ RHEL5
✓ RHEL7 server
✓ RHEL7 server minimal
✓ Ubuntu 16.04-desktop
------- Comment #47 From cendio 2016-09-26 14:07:10 -------
Verified LSB step installation on SLES11 sp2 and SLES12 sp1, works as expected.
------- Comment #50 From cendio 2016-09-26 16:05:59 -------
(In reply to comment #47)
> Verified LSB step installation on SLES11 sp2 and SLES12 sp1, works as expected.

Also verified on debian 8
------- Comment #51 From cendio 2016-09-26 16:11:18 -------
Works on Fedora 24 server as well. I have to add though that you have to
manually install:

> dnf install libutil.so.1 libncurses.so.5 libnspr4.so libpam.so.0 libnss3.so libssl3.so librt.so.1 libz.so.1 libgcc_s.so.1 libcrypt.so.1 libpthread.so.0 libdl.so.2 libm.so.6 libX11.so.6 libc.so.6 net-tools /usr/sbin/sendmail procps ghostscript xauth 
> dnf install pygtk2 pygtk2-libglade.x86_64 selinux-policy-devel.noarch

The list provided by tl-setup says netstat, gs, and pgrep, while the package
names in Fedora is net-tools, ghostscript and procps. However, from my
understanding, we can't know the package names in tl-setup here.

Closing.
------- Comment #52 From cendio 2016-09-29 11:25:28 -------
Ran into a problem with tl-setup on tl-4.7.0 build 5248 on a fully updated
Fedora 24:

/var/log/tlsetup.log:

> 2016-09-29 11:06:20,916: Resolving packages...
> 2016-09-29 11:06:23,610: resolving package 'libncurses.so.5()(64bit)' for installation.
> 2016-09-29 11:06:24,674: package 'libncurses.so.5()(64bit)' provides package 'ncurses-compat-libs'
> 2016-09-29 11:06:24,956: package 'ncurses-compat-libs-6.0-5.20160116.fc24.x86_64' flagged for installation
> 2016-09-29 11:06:26,532: Packages to install:
> 2016-09-29 11:06:26,532:  - ncurses-compat-libs-6.0.x86_64
> 2016-09-29 11:06:28,245: Running Transaction Check
> 2016-09-29 11:06:28,254:   failed to install packages with reason: [u'ERROR with transaction check vs depsolve:', 'ncurses-base = 6.0-5.20160116.fc24 is needed by ncurses-compat-libs-6.0-5.20160116.fc24.x86_64']
> 2016-09-29 11:06:47,352: tl-setup aborted by user

> $ rpm -q ncurses-base
> ncurses-base-6.0-6.20160709.fc24.noarch



tl-setup tries to install an old version of ncurses-compat-libs that fails
because it has dependencies on an older ncurses-base. tl-setup should install
the newest version.
------- Comment #53 From cendio 2016-09-29 13:35:14 -------
(In reply to comment #52)
> Ran into a problem with tl-setup on tl-4.7.0 build 5248 on a fully updated
> Fedora 24:
> 
> /var/log/tlsetup.log:
> 
> > 2016-09-29 11:06:20,916: Resolving packages...

Fedora 24 uses DNF, which we don't support, so how did you manage this?
------- Comment #55 From cendio 2016-09-29 14:04:41 -------
(In reply to comment #53)
> (In reply to comment #52)
> > Ran into a problem with tl-setup on tl-4.7.0 build 5248 on a fully updated
> > Fedora 24:
> > 
> > /var/log/tlsetup.log:
> > 
> > > 2016-09-29 11:06:20,916: Resolving packages...
> 
> Fedora 24 uses DNF, which we don't support, so how did you manage this?

By doing "dnf install yum" apparently.
------- Comment #57 From cendio 2016-10-03 14:17:36 -------
(In reply to comment #52)
> tl-setup tries to install an old version of ncurses-compat-libs that fails
> because it has dependencies on an older ncurses-base. tl-setup should install
> the newest version.

Verified that the bug exist on 4.7.0beta1 and that it is fixed in build 5252.
tl-setup works great now.