Zen

Source string Source string

363/10000 · 363

The string is read only.

English Actions
If you're going to use the source, you *MUST* remove the RPMS first.
Compiling mono is not a trivial matter and may not even work (when you download the source, you must also _make get-monolite-latest_ which grabs a version of the corelib and mcs which are need for compiling the main C# compilers - the monolite-latest does not always work and you end up without a working copy of Mono.
rpmlint and mono packages
rpmlint is a program that checks packages for common problems. For mono packages, some of the rpmlint messages can be disregarded.
Mono installs binaries in %\{_libdir}//bin with symlinks back to /usr/bin. rpmlint is not happy with this and generates an error (which is the correct behaviour). It will also not recognise that mono libraries are not ELF format and may generate errors on this as well.
rpmlint will also pick up on any .pc file installed in the rpm (see below).
-devel packages
Mono packages *must* package .pc files in a -devel package, even if that is the only file that will be included. If we were to permit .pc files in non-devel packages, then we'll have non-devel packages that depend on -devel packages, inflating the install needlessly.
Empty debuginfo
Sometimes building mono packages results in an empty debuginfo sub package, one without any files to install. See Packaging/Debuginfo
Incorrect Behaviours
Distributing Prebuilt Assemblies
Because mono .dlls are generally architecture independent, upstream may ship tarballs which install precompiled .dlls and .exes. All packages *must* build from source so the packager needs to watch out for these tarballs and be certain not to use them. (This can sneak in during upgrades as well, so the packager has to make sure they're building from source every time the tarball is changed.)
Distributing .DLLs from other projects
The Mono project's website makes https://www.mono-project.com/Assemblies_and_the_GAC#Libraries_with_Unstable_APIs[this suggestion]
Sometimes developers might want to distribute a library to other developers but they might not have a library that is API stable or has not matured enough over time to guarantee the backwards-compatibility of their libraries or they are not willing to maintain multiple packages of the various versions for users.
[...]
To solve this problem, we recommend that:
* The library developer ships a properly configured pkg-config file.
* The library consumers include an "update-libraries" target on their Makefile that will import the latest version of a library from a system directory into their application source code distribution.
* The library consumers ship this library as part of their package.
This suggestion may make it easier for applications targetting unstable library APIs but it is *_extremely poor practice_*. Using libraries in this manner has all the same problems as linking with static libraries, most notably that the application can suffer from security holes in the library long after it is fixed upstream. Mono applications in Fedora cannot include upstream DLLs (even if they are compiled from source). This is a blocker issue and *must* be fixed.
There are several techniques for detecting the presence of these libraries, none of them fool proof. If you know of a better method, please add it:
Upstream tarball contains .dlls that were not rebuilt from source contained in the package.
Look through the installed .dlls for any that have the same name as system .dlls or are suspiciously out of place (Package is myDiary and contains mysql.dll, sqlite.dll, and gtk-sharp.dll)
Source directories look odd:
PKGNAME/
src/
data/
libs/
gtk-sharp/
atk-sharp/
Redefining _libdir
Packagers should avoid redefining _libdir in their spec file. Redefinition of this macro will cover up problems instead of helping fix them. Packagers should:
Identify which directories the files should install into according to the xref:index.adoc[Packaging Guidelines] .
Patch the packages build scripts to install to those locations.
Identify places where the package has hardcoded the old locations instead of the new ones and fix those.
Either report the issues to upstream or submit patches. Note that upstream projects are generally receptive to patches that allow package builders to redefine install locations at build time -- less receptive to patches which change upstream's hardcoded defaults to our hardcoded defaults.
Defining target
Was done for a brief period when we attempted to package mono apps as noarch. It was not necessary then (the actual fix was to stop using AC_CANONICAL_* in the configure.ac file) and it is definitely not needed now that we are no longer building noarch mono packages.

Loading…

User avatar None

Source string added
Sometimes developers might want to distribute a library to other developers but they might not have a library that is API stable or has not matured enough over time to guarantee the backwards-compatibility of their libraries or they are not willing to maintain multiple packages of the various versions for users.
[...]
To solve this problem, we recommend that:
4 years ago
Browse all string changes

Things to check

Ellipsis

The string uses three dots (...) instead of an ellipsis character (…)

Reset

Glossary

English English
No related strings found in the glossary.

997962 String information

Source string description
type: delimited block .
Flags
no-wrap, read-only
Source string location
./pages/Mono.adoc:85
String age
4 years ago
Last updated
a year ago
Source string age
4 years ago
Translation file
pot/master/pages/Mono.pot, string 34