[opensuse-factory] discussion about re-naming library packages such as "slang" to "libslang"
hi SUSErs ! There is a package needed mainly for midnight commander called "slang" - as far as I understand it is a text-display library similar to ncurses. Because this is library, maybe it would be smart to rename it to "libslang", so that it will be easier to manipulate such lib* packages? What about other similar packages ? (like zlib / libz) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Alexey Eremenko schrieb:
There is a package needed mainly for midnight commander called "slang" - as far as I understand it is a text-display library similar to ncurses. Because this is library, maybe it would be smart to rename it to "libslang", so that it will be easier to manipulate such lib* packages?
The current policy is that the RPM package names should be identical to the basename of the upstream tarball unless there is a technical reason why it cannot be named this way. Reference: http://developer.novell.com/wiki/index.php/Spc
What about other similar packages ? (like zlib / libz)
I'm _strongly_ against renaming existing packages for reasons other than a technical problem which requires the package to be renamed. This is a major annoyance for users, causes upgrade problems and inconvencies in all areas. Just imagine you were a support provider (e.g. user forums, IRC), you would have to give different answers for different SUSE versions. In the "RPM world" (i.e. Fedora, SUSE), the common rule is what we currently have. Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Some clarifications:
The current policy is that the RPM package names should be identical to the basename of the upstream tarball unless there is a technical reason why it cannot be named this way.
Examples of technical reasons include: - Multiple versions of a package are shipped, in this case only the name of one version can match the upstream tarball, all other versions get a shortened form of the version number squeezed into the package name. - The upstream release name contains illegal characters.
I'm _strongly_ against renaming existing packages for reasons other than a technical problem which requires the package to be renamed.
This should read: Discussing new rules is of course interesting and fine, but if a new naming policy is agreed on as a result of this, it should be applied to new packages only. Existing packages should not be renamed unless they either change their meaning or there are packaging changes which force changing the name. The technical problems with renamed packages are: - The package manager somehow has to know that the new package replaces the old package. This is usually solved via Provides/Obsoletes, but it pollutes the namespace: An obsoleted package name can effectively never be re-introduced again, and even the slightest mistake in this area can have very "interesting" results. - YaST contains hardcoded package lists in several places which don't work with Provides, but only with the real package names, so renamed packages can only be handled by changing the code and nobody can guarantee that all occurances of obsolete packages are found and cought in time. - 3rd party developers use the existing package names to express dependencies (Requires/BuildRequires), changes in this area result in very ugly %if/%else blocks that make the spec files harder to read and maintain. These cannot be fixed as easily as the ones in the distribution. If the 3rd party developer doesn't notice the change, the package gets broken. Note that I do think your proposal has advantages, but in order to be really useful, it would require major packaging changes. As an example, how would you handle a package that contains both shared libraries and executables? Debian-derived distributions have a policy to split all such packages so that the executables are in a package named like the upstream release and a library package that gets a "lib" prefix and a suffix based on the interface version of the shared library. This is an advantage because it means you can have an arbitrary number of different library versions installed, but requires much more packaging work. You would have to update the BuildRequires of all packages all the time, and you would have to manually keep the package name in sync with the interface version with each upgrade. It's painful, I predict it won't work and for a centrally developed distribution it's not really necessary. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 2006-11-27 23:10:39 +0200, Alexey Eremenko wrote:
There is a package needed mainly for midnight commander called "slang" - as far as I understand it is a text-display library similar to ncurses. Because this is library, maybe it would be smart to rename it to "libslang", so that it will be easier to manipulate such lib* packages?
now .... could you explain why renaming helps to manipulate those?
What about other similar packages ? (like zlib / libz) no?
darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (3)
-
Alexey Eremenko
-
Andreas Hanke
-
Marcus Rueckert