fedora-docs-l10n/packaging-guidelines/master/pages/index

Zen

Source string Source string

English

Macros

Needs editing

The string is read-only.

Skip

	English	Actions
	`+Icon=/usr/share/pixmaps/comical.png+`
	Short name without file extension:
	`+Icon=comical+`
	The short name without file extension is preferred, because it allows for icon theming (it assumes .png by default, then tries .svg and finally .xpm), but either method is acceptable.
	`+.desktop+` File Creation
	If the package doesn't already include and install its own .desktop file, you need to make your own. You can do this by including a .desktop file you create as a Source: (e.g. Source3: %\{name}.desktop) or generating it in the spec file. Here are the contents of a sample .desktop file (comical.desktop):
	[Desktop Entry] Name=Comical GenericName=Comic Archive Reader Comment=Open .cbr & .cbz files Exec=comical Icon=comical Terminal=false Type=Application Categories=Graphics;
	`+desktop-file-install+` Usage
	It is not simply enough to just include the .desktop file in the package, one MUST run `+desktop-file-install+` (in `+%install+`) OR `+desktop-file-validate+` (in `+%check+` or `+%install+`) and have `+BuildRequires: desktop-file-utils+`, to help ensure .desktop file safety and spec-compliance. `+desktop-file-install+` MUST be used if the package does not install the file or there are changes desired to the .desktop file (such as add/removing categories, etc). `+desktop-file-validate+` MAY be used instead if the .desktop file's content/location does not need modification. Here are some examples of usage:
	desktop-file-install \ --dir=%{buildroot}%{_datadir}/applications \ %{SOURCE3}
	desktop-file-install \ --add-category="AudioVideo" \ --delete-original \ --dir=%{buildroot}%{_datadir}/applications \ %{buildroot}/%{_datadir}/applications/foo.desktop
	desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop
	Do not apply a vendor tag to .desktop files (using --vendor).
	AppData Files
	Packages containing graphical applications should include AppData files. See xref:AppData.adoc[Packaging:AppData] for the relevant guidelines.
	Macros
	Packagers are strongly encouraged to use macros instead of hard-coded directory names (see xref:RPMMacros.adoc[RPMMacros]). However, in situations where the macro is longer than the path it represents, or situations where the packager feels it is cleaner to use the actual path, the packager is permitted to use the actual path instead of the macro. There are several caveats to this approach:
	The package must be consistent. For any given path, within the same spec, use either a hard-coded path or a macro, not a combination of the two.
	%\{_libdir} must always be used for binary libraries due to multi-lib, you may not substitute a hard-coded path.
	Macros with names beginning with underscores are generally considered to be implementation details internal to RPM and its associated macro packages and SHOULD NOT be referenced in specfiles except to set their values in order to influence RPM behavior. This implies that macro forms of system executables SHOULD NOT be used. For example, `+rm+` should be used in preference to `+%{__rm}+`. However, in some cases needed data are simply not provided under names which are not prefixed with underscores. If that is the case, the macro named with leading underscores MAY be used. Authors of macro packages are encouraged to avoid using leading underscores when naming macros which are intended to be used in specfiles (as opposed to being set).
	Having macros in a Source: or Patch: line is a matter of style. Some people enjoy the ready readability of a source line without macros. Others prefer the ease of updating for new versions when macros are used. In all cases, remember to be consistent in your spec file and verify that the URLs you list are valid. spectool (from the rpmdevtools package) can aid you in checking that whether the URL contains macros or not.
	If you need to determine the actual string when it contains macros, you can use rpm. For example, to determine the actual Source: value, you can run:
	rpm -q --specfile foo.spec --qf "$(grep -i ^Source foo.spec)\n"
	`+%autosetup+`
	As an alternative to the usual `+%setup+` macro, the `+%autosetup+` can be used. In addition to the normal %setup tasks, it will apply all defined Patch# items in the spec automatically. It is also capable of handling VCS formatted patch files, but this will require additional BuildRequires, and assumes that _all_ patch files in the spec are formatted for that single VCS type. For this reason, it is not recommended that you specify a VCS with `+%autosetup+`. For more details on proper use of `+%autosetup+`, refer to the https://rpm-software-management.github.io/rpm/manual/autosetup.html[RPM documentation].
	Using `+%{buildroot}+` and `+%{optflags}+` vs `+$RPM_BUILD_ROOT+` and `+$RPM_OPT_FLAGS+`
	There are two styles of defining the rpm Build Root and Optimization Flags in a spec file:
	\| \|macro style \|variable style \|Build Root \|%\{buildroot} \|$RPM_BUILD_ROOT \|Opt. Flags \|%\{optflags} \|$RPM_OPT_FLAGS
	There is very little value in choosing one style over the other, since they will resolve to the same values in all scenarios. You should pick a style and use it consistently throughout your packaging.
	Mixing the two styles, while valid, is bad from a QA and usability point of view, and should not be done in Fedora packages.
	Why the `+%makeinstall+` Macro Should Not Be Used

Loading…

None

Source string added

English 0 characters edited

5 years ago

Browse all string changes

Things to check

Multiple failing checks

Following checks are failing:

Inconsistent: French, Finnish
Unchanged translation: French

Reset

Glossary

English	English
No related strings found in the glossary.

1002828 String information

Source string description

type: Title ==

Flags

no-wrap, read-only

Source string location

./pages/index.adoc:1965

String age

5 years ago

Last updated

5 months ago

Source string age

5 years ago

Translation file

pot/master/pages/index.pot, string 402

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.