Qt Headers And Libraries Not Found Fedora
Mina Spartin
The boost-devel package is the only package that has the boost header files, and it requires the other packages, so the answer to your question is: No, there are no packages you can install that would only provide the headers. Fedora packages typically have their -devel packages require the other package that includes any libraries used to compile using the headers in the package, as is in this case.
Most of Boost is header only library. But there are a few that needs to be compiled. The answer from jsbillings lists them all. If you will not be using any of those libraries that require the compiled libraries then you dont have to install them. Just install the headers only.
However I really wonder why the 1 of diskspace matters here? esp. as I wouldn't be surprised to find that some of the headers don't guarantee that they'll never need a shared library (even though they are implemented that way now).
The Packaging Guidelines are a collection of common issuesand the severity that should be placed on them.While these guidelines should not be ignored,they should also not be blindly followed.If you think that your package should be exempt from part of the Guidelines,please bring the issue to the Fedora Packaging Committee.
These documents cover the fine details of acceptable Fedora packagingand while they may include various examplesthey will not be particularly useful as a tutorial.They also do not cover the detailsand policies relating to gaining accessto the Fedora repositories as a packager,or the mechanics of actually creating and releasing packagesas part of the distribution.For documents which cover those issues,please see the following:
The original author of these documents isTom 'spot' Callaway,though they were originally based on many other documents.They have been significantly modified over the yearsby many members of the Packaging Committee.
In general,these guidelines apply to the currently released,non-end-of-life versions of Fedora,as well as the development version of Fedora (Rawhide).If a particular portion of these guidelines is relevantonly to a subset of those releases,this will be specifically noted.However, please note that Rawhide can change rapidly,and there will be times when changes are visible therewhich are not yet reflected here.
The guidelines also to some degree cover packages for EPEL,but only when combined with theEPEL packaging guidelines.Fedora packaging changes far more rapidly than EPEL packaging,so over time these guidelines will drift further awayfrom any particular EPEL releaseand for the older supported EPEL releasethe differences can be quite significant.Portions of these guidelines which do not apply to EPELwill not generally be indicated.
If, in a guideline, the language "should" or "is suggested" is usedand it is not feasible for the package to conform to that guideline,the packager may deviate from the it.The nature of the deviation and the reasoning behind itMUST be documented in the specfile.
Where the language "must", "is required to" or "needs to" is used,the packager may deviate from the guidelineonly with approval from the packaging committee.Please follow the procedure at thePackaging Committeepage for making these requests.
You should review the information regardinglicenses determined to be allowed in Fedoraand the Licensing Guidelinesto ensure that your package is licensed appropriatelyand that the license is properly indicated.
Packagers MUST NOT add any Fedora trademark assetsincluding the Fedora logo,Fedora logo icons,or graphics that include the Fedora logo.Those assets MUST be added to the fedora-logos package.Your packages(s) install the logos by depending on the fedora-logos package.If the upstream contains Fedora trademark assetsthat you believe are used inappropriately,email le...@fedoraproject.org
This is because the Fedora logo is a trademark,which are handled under a different legal framework than code.It must only be distributed under terms that protect the trademark.Keeping Fedora trademarks separate in their own packageinstead of scattered across various other packagesis also an essential practice for enabling remixesthat necessarily mustnot use the Fedora trademark,and instead roll their own *-logos packageor use the generic-logos package.
Many language- or domain-specific guidelines refer to "libraries","modules", "plug-ins" or other terms specific to the language ordomain. This is specifically important to packagenaming. Some applications may include libraries, and some librariesmay include applications, so the distinction is not always clear.
If the primary purpose of a packageis to provide executables to be run by users,it SHOULD be packaged as an application.If it also includes libraries which may be importedor linked to by other code,see Mixed Use Packages below.
If the primary purpose of a packageis to provide libraries intended to be imported or loaded into other code,it is considered a library and MUST be packaged as such.If it contains utility programs that can be run by users as well,see Mixed Use Packages below.
It is left to the packager to determine the primary purpose of a package.Often times upstream will already have done thiswith their choice of namingand that choice SHOULD be followed by the Fedora packager.
Many packages, regardless of their primary purpose,include both applications and libraries.In this case one or both SHOULD be packaged in subpackagesin order to allow other applications to depend on only the libraryand not the associated application(s).Installing an application that depends on a library or serviceshould not automatically pull in other applicationsassociated with that library or service.
Desktop applications MUST NOT depend on other desktop applicationsunless strictly required.In particular, packages that contain a visible .desktop file(a .desktop file that does not contain the line NoDisplay=true)SHOULD NOT have a Requires,Recommends,or Supplementson any other package containing a visible desktop file,directly or indirectly.
The spec file ("spec") is a fundamental element in the packaging workflow.Any change that is made to the package will include a change to the spec.Because packages in Fedora are maintained by a community of packagersas well as automated tooling,it is important for the specs to follow certain conventions.The bulk of these packaging guidelines involves what goes into a spec,but here are a few general items.
To help facilitate legibility,only macros and conditionals for Fedora and EPELare allowed to be used in Fedora Packages.Use of macros and conditionals for other distributions,including Fedora derivatives,is not permitted in spec files of packages in the main Fedora repositoriesunless those macros and conditionals are also present in Fedora.
The verification method requires an OpenPGP keyring filewith one or more public keys from the upstream project.The keyring shall contain all the keys that are trustedto certify the authenticity of the sources,and MUST NOT contain any other keys.
Ideally the upstream project publishes such a keyring as a downloadable file.You shall download that fileand do everything you reasonably can to verify that it is authentic.Then you shall add it unmodified to the package SCM,and provide its URL in the spec fileso that others can verify it.The URL MUST use HTTPSor a similarly authenticated protocol if at all possible.
Even if you are unable to verify the key at the first addition,it still enhances security in a trust-on-first-use way.It will ensure that future attacks will be detectedif the key is the right one,or that a current attack will be detected laterif future releases are signed by the correct key.
When source file verification is done,it MUST be done first in the %prep section of the spec file,before any potentially compromised code is executed.The verification MUST be done with the macro %gpgverify,which expands into a commandwhose parameters shall be the pathnames of the keyring,the signature and the signed file.BuildRequires: gnupg2 is necessary for the verification to work.
Any detached signature file(e.g. foo.tar.gz.asc or foo.tar.gz.sig)must be uploaded to the package lookaside cache alongside the source code,while the keyring must be committed directly to the package SCM.
If the upstream tarball of a package needs to be modified,for example because it contains forbidden items,then the tarball cannot be verified as part of the build process.In this casethe upstream OpenPGP keyring must still be included in the package SCMand the instructions/script used to build the stripped-down tarballneeds to verify the upstream source.
If the upstream project does not publish a keyring file(for example if they publish only a fingerprint on their websiteand refer to a keyserver network for downloading the key),then you may need to create a keyring after you have verified the key.In this case there is no upstream URL to the keyring,so instead you should document how you created the keyringin a comment in the spec file.A minimal keyring with the key with the fingerprint7D33D762FD6C35130481347FDB4B54CBA4826A18can be created with the following command:
If you need help getting your package compliant to this guideline,or if you do not know what to do if a build fails on a signature verification,then you should seek help on the Fedora devel mailing listbefore circumventing the check,to make sure that you do not build compromised software.
All Fedora packages must successfully compile and buildinto binary rpms on at least one supported primary architecture,except where the package is useful only on a secondary architecture(such as an architecture-specific boot utility, microcode loader,or hardware configuration tool).Fedora packagers should make every effort to support allprimary architectures.
If a Fedora package does not successfully compile, build or work on an architecture,then those architectures should be listed in the spec in ExcludeArch.Each architecture listed in ExcludeArchneeds to have a bug filed in bugzilla,describing the reason that the package does notcompile/build/work on that architecture.The bug number should then be placed in a comment,next to the corresponding ExcludeArch line.New packages will not have bugzilla entries during the review process,so they should put this description in the commentuntil the package is approved,then file the bugzilla entry,and replace the long explanation with the bug number.The bug should be marked as blocking one (or more)of the following bugs to simplify tracking such issues:
7fc3f7cf58