Added as bug so we don't forget to think about it. There is not a known
impediment to multiple versions of the interface set through the LSB linker and
symbol versioning/library versioning. However, if there are command differences
that would be visible (e.g. if there's more of a move to POSIX alignment in the
upstreams), we don't have a mechanism for that. From the wiki page:
Shell scripts can query the distribution to see which versions are supported via
the lsb_release command. However, this is not sufficient to provide backwards
compatibility if we need to make incompatible changes in the future. (For
example, if LSB 4.0 makes changes that brings it into closer alignment to
POSIX.) This can be done by requiring the hypothetical LSB 4.0 application to
declare the fact that they are expecting the LSB 4.0 behavior. (For example, we
might require that all LSB 4.0 applications define some environment variable
that changes the behavior of the shell programs, so that the LSB 2.0 and 3.0
applications still get the same default behavior, but LSB 4.0 get the new,
POSIX-aligned behavior. This could be done via defining a environment variable
such as POSIXLY_CORRECT, for example.) The important point is that if we want to
make changes to how the shell programs function, and we also want to allow
distributions to be simultaneously certify against LSB 3.0 and 4.0, it will be
important that we remember to require LSB 4.0 application to identify themselves
so that the shell commands can simultaneously satisfy both the LSB 2.0/3.0 and
LSB 4.0.
--
Configure bugmail: http://bugs.linuxbase.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.