fedora-docs-l10n/packaging-guidelines/master/pages/index — Finnish @ Fedora Weblate: Debuginfo Packages

Zen

Translation

English type: Title ==

Finnish

Needs editing

Skip

	English	Finnish	Actions
	If a packager wants to use conditional macros in a spec file to make it easier to switch between two different compilers, then the following macros names should be used:
	%bcond_with toolchain_clang %bcond_with toolchain_gcc
	Packagers may also use the %build_cc, %build_cxx, or %build_cpp macros in the spec file in place of hard-coding the compiler name. The values of these variables are controled by setting the %toolchain macro to either clang or gcc.
	Compiler Flags
	Compilers used to build packages must honor the applicable compiler flags set in the system rpm configuration. Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build.
	For C, {cpp}, and Fortran code, the xref:RPMMacros.adoc#build-flags-macros-and-variables[%\{optflags} macro] contains these flags. Overriding these flags for performance optimizations (for instance, -O3 instead of -O2) is generally discouraged. If you can present benchmarks that show a significant speedup for this particular code, this could be revisited on a case-by-case basis. Adding to and overriding or filtering parts of these flags is permitted if there's a good reason to do so; the rationale for doing so must be documented in the specfile.
	There are certain, security related flags that are commonly allowed. These flags may degrade performance slightly but the increased security can be worthwhile for some programs.
	PIE
	PIE adds security to executables by composing them entirely of position-independent code. Position-independent code (PIC) is machine instruction code that executes properly regardless of where in memory it resides. PIE allows Exec Shield to use address space layout randomization to prevent attackers from knowing where existing executable code is during a security attack using exploits that rely on knowing the offset of the executable code in the binary, such as return-to-libc attacks.
	In Fedora, PIE is enabled by default. To disable it in your spec, add:
	%undefine _hardened_build
	If your package meets any of the following criteria you MUST NOT disable the PIE compiler flags:
	Your package is long running. This means it's likely to be started and keep running until the machine is rebooted, not start on demand and quit on idle.
	Your package has suid binaries, or binaries with capabilities.
	Your package runs as root.
	Debuginfo Packages	Virheenjäljitystieto-paketit
	Packages should produce useful `+-debuginfo+` packages, or explicitly disable them when it is not possible to generate a useful one, but rpmbuild would do it anyway. Whenever a `+-debuginfo+` package is explicitly disabled, an explanation why it was done is required in the specfile. Debuginfo packages are discussed in more detail in a separate document, xref:Debuginfo.adoc[Packaging:Debuginfo].
	Devel Packages
	Fedora packages must be designed with a logical separation of files. Specifically, -devel packages must be used to contain files which are intended solely for development or needed only at build-time. This is done to minimize the install footprint for users. There are some types of files which almost always belong in a -devel package:
	Header files (foo.h), usually found in /usr/include
	Static library files when the package does not provide any matching shared library files. See <<packaging-static-libraries>> for more information about this scenario.
	Unversioned shared system library files, when a matching versioned shared system library file is also present. For example, if your package contains:
	/usr/lib/libfoo.so.3.0.0 /usr/lib/libfoo.so.3 /usr/lib/libfoo.so
	The versioned shared library files (/usr/lib/libfoo.so.3.2.0 and /usr/lib/libfoo.so.3) are necessary for users to run programs linked against libfoo, so they belong in the base package. The other, unversioned, shared library file (/usr/lib/libfoo.so) is only used to actually link libfoo to code being compiled, and is not necessary to be installed on a users system. This means that it belongs in a -devel package. Please note that in most cases, only the fully versioned shared library file (/usr/lib/libfoo.so.3.2.0) is an actual file, all of the other files are symbolic links to it. When a shared library file is only provided in an unversioned format, the packager should ask upstream to consider providing a properly versioned library file. However, in such cases, if the shared library file is necessary for users to run programs linked against it, it must go into the base package. If upstream versions the shared library file at a future point, packagers must be careful to move to the versioned layout described above.
	Unversioned Shared Objects
	As an additional complication, some software generates xref:Unversioned_shared_objects.adoc[unversioned shared objects] which are not intended to be used as system libraries. These files are usually plugins or modular functionality specific to an application, and are not to be located in the ld library paths or cache. These types of unversioned shared objects do not need to go into a -devel package. They are only loaded at runtime and should be included in a private directory of the main package.
	For specific details about how to deal with these types of DSOs, please see xref:Unversioned_shared_objects.adoc[unversioned shared objects] for detailed guidance.
	There are some notable exceptions to this packaging model, specifically:
	compilers often include development files in the main package because compilers are themselves only used for software development, thus, a split package model does not make any sense.
	When in doubt as to whether a file belongs in the base package or in -devel, packagers should consider whether the file is necessary to be present for a user to use or execute the functionality in the base package properly, or if it is only necessary for development. If it is only necessary for development, it must go into a -devel package.
	As with all Fedora Packaging Guidelines, it is recognized that there are unique situations that fall outside of the boundaries of this model. Should you come across such a case, please open a ticket with the {packaging-committee} and explain it to us so that we can extend the Guidelines to address it.

Loading…

copperi

Translation changed

English

Finnish 25 characters edited Current translation

3 years ago

None

Source string changed

English 8 characters edited

3 years ago

Browse all string changes

Things to check

Reused translation

Other source string: “Debuginfo packages”

Reset

Glossary

English	Finnish
No related strings found in the glossary.

8907485 String information

Source string description

type: Title ==

Flags

no-wrap

Source string location

pages/index.adoc:1323

String age

3 years ago

Last updated

2 months ago

Source string age

3 years ago

Translation file

po/fi/master/pages/index.po, string 269

Shortcut	Action
`?`	Open available keyboard shortcuts.
`Alt` + `Home`	Navigate to the first translation in the current search.
`Alt` + `End`	Navigate to the last translation in the current search.
`Alt` + `PageUp` or `Ctrl` + `↑` or `Alt` + `↑` or `Cmd` + `↑` or	Navigate to the last translation in the current search.
`Alt` + `PageDown` or `Ctrl` + `↓` or `Alt` + `↓` or `Cmd` + `↓` or	Navigate to the next translation in the current search.
`Ctrl` + `Enter` or `Cmd` + `Enter`	Submit current form; this works the same as pressing Save and continue while editing translation.
`Ctrl` + `Shift` + `Enter` or `Cmd` + `Shift` +`Enter`	Unmark translation as Needing edit and submit it.
`Alt` + `Enter` or `Option` + `Enter`	Submit the string as a suggestion; this works the same as pressing Suggest while editing translation.
`Ctrl` + `E` or `Cmd` + `E`	Focus on translation editor.
`Ctrl` + `U` or `Cmd` + `U`	Focus on comment editor.
`Ctrl` + `M` or `Cmd` + `M`	Shows Automatic suggestions tab.
`Ctrl` + `1` to `Ctrl` + `9` or `Cmd` + `1` to `Cmd` + `9`	Copies placeable of a given number from source string.
`Ctrl` + `M` followed by `1` to `9` or `Cmd` + `M` followed by `1` to `9`	Copy the machine translation of a given number to current translation.
`Ctrl` + `I` followed by `1` to `9` or `Cmd` + `I` followed by `1` to `9`	Ignore one item in the list of failing checks.
`Ctrl` + `J` or `Cmd` + `J`	Shows the Nearby strings tab.
`Ctrl` + `S` or `Cmd` + `S`	Focus on search field.
`Ctrl` + `O` or `Cmd` + `O`	Copy the source string.
`Ctrl` + `Y` or `Cmd` + `Y`	Toggle the Needs editing checkbox.
`→`	Browse the next translation string.
`←`	Browse the previous translation string.