There is a default list of system packages for Nixos:
https://github.com/NixOS/nixpkgs/blob/582313bafef4c81cb6df2dcf2ece4757eb5c8082/nixos/modules/config/system-path.nix
How can I exclude some of predefined packages from environment.systemPackages (for example, texinfo)?
The NixOS module system does not currently support this. You can use mkForce to override all definitions of an option value at the default priority level, but that will get rid of all predefined packages, which is not what you want.
Related
I have a fairly new project on github that produces a shared library. Going forward, I would like to use semantic versioning (as described at semver.org) for the shared library major/minor/patch numbers in the file name. The project uses CMake. The CMakeLists.txt file refers to CPACK_PACKAGE_VERSION_MAJOR, CPACK_PACKAGE_VERSION_MINOR and CPACK_PACKAGE_VERSION_PATCH, and sets these to default values if they are not passed in on the command line.
My plan is to branch on ABI changes and API additions, according to semantic versioning principles.
I know github has support for creating and naming release packages containing the project source based on git tags. But I do not see a way to propagate the major, minor and patch numbers to the shared library name when the github user builds a release on their machine.
For example, if I have a branch called, myproj_1_2, and a release tag called myproj_rel_1_2_9, is there a way to have the shared library built by a user be name libmyproj.so.1.2.9?
Is this just a matter of documenting that a user should pass the build name information on the cmake command line, and the have the CMakeLists.txt file parse this and set CPACK_PACKAGE_VERSION_MAJOR, CPACK_PACKAGE_VERSION_MINOR and CPACK_PACKAGE_VERSION_PATCH accordingly, or is there a more elegant way to do this?
Your statement about how CPACK_PACKAGE_VERSION_XXX is set is incorrect. The CPack variables in question are set by the project command if the project command specifies versioning. So when you create the 1.2.9 branch you would set 1.2.9 as the version number in the project command.
From CPack Help
CPACK_PACKAGE_VERSION_MAJOR
Package major version. This variable will always be set, but its default value depends on whether or not version details were given to
the project() command in the top level CMakeLists.txt file. If version
details were given, the default value will be
CMAKE_PROJECT_VERSION_MAJOR. If no version details were given, a
default version of 0.1.1 will be assumed, leading to
CPACK_PACKAGE_VERSION_MAJOR having a default value of 0.
Project command
> project(<PROJECT-NAME>
> [VERSION <major>[.<minor>[.<patch>[.<tweak>]]]]
> [DESCRIPTION <project-description-string>]
> [HOMEPAGE_URL <url-string>]
> [LANGUAGES <language-name>...])
If you don't want to set the VERSION via the project command then there are multiple other ways of setting the relevant variables.
Examples are located:
https://cmake.org/cmake-tutorial/
Also look at how CMake handles versions:
https://gitlab.kitware.com/cmake/cmake/blob/master/Source/CMakeVersionSource.cmake
https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmVersionConfig.h.in
Another example of how to get git meta data for setting version related information:
https://github.com/pmirshad/cmake-with-git-metadata/blob/master/CMakeLists.txt
I am pretty new to Haskell as well as stack.
import Data.Set
import Data.Stack
The statements above trigger compilation error: Could not find module 'Data.Set'. Perhaps you meant 'Data.Int'. I tried to google and found nothing similar.
Hence, my question is: do I need to specify external dependencies manually or just my stack build command somewhy fails to grab appropriate modules from somewhat cache or repository?
In case I have to specify my dependencies manually, should I prefer .cabal or .yaml? What's the correct way to deal with versioning?
[Do] I need to specify external dependencies manually [...]?
Yes.
Since you are using Stack, it is easy to specify the dependent packages you import in your code. Depend on your Stack version, the default configuration might be a little bit different:
If you created your project with the latest version of Stack, you will see package.yaml in the root of your project (hpack is used in this case to specify the configurations). You need to add package dependencies there, e.g., containers for Data.Set. Here's an example of a dependencies section in one of my projects:
dependencies:
- base >= 4.7 && < 5
- containers
- time
- network
- bytestring
If you are using an older version of stack and do not see package.yaml, you need to edit your-project-name.cabal to add the dependencies. Here's the complete document telling you how to do it: https://docs.haskellstack.org/en/stable/GUIDE/#adding-dependencies
Personally, I prefer the new system with hpack (package.yaml). Basically, it is simpler, and it saves you time declaring all modules you have (not about dependency). If you have package.yaml, do not edit .cabal, which is automatically generated by hpack.
I was wondering whether Node.js/npm include any kind of exension mechanism comparable to Python setuptools' "entry points".
So, in short:
is there any way I can do dynamic discovery of services provided by other packages using npm?
if not, what would be the best way to implement something similar? Specifying the extension name in the main module's configuration file seems to be the logical solution, but I wonder whether something "automatic" can be done.
I'm not aware of any builtin mechanism to do this.
One viable way of doing it yourself:
I made a small tool (Jumpstart) to quickly create project scaffolding from templates with placeholders, and I used a kind of plugin mechanism for that. It basically comes down to that the Jumpstart script searches for modules named jumpstart-* "adjacent" to where the module itself is installed. So it would work for both local and global installations. If installed locally, it would search the other local modules (on the same level) and if global, it searches the other global modules.
Note that here, "search" comes down to a simple fs.exists check to see if there's a Jumpstart template module with a particular name installed. However, nothing would stand in the way to actually get a full list of all installed packages matching the jumpstart-* pattern, and loading all at once. I could also search up the entire directory tree for node_modules directories and do the same. There's no point in doing this for this particular program, however.
See https://npmjs.org/package/jumpstart for docs.
The only limitation to this technique is that all modules must be named in a consistent fashion. Start with some string, end with some string, something like that. Any rogue packages polluting the namespace could be detected by doing further checks on a package contents: What files does it contain? What kind of object does its main module export? etc.
Brunch also uses a plugin mechanism. This one actually deals with file extensions, so is more relevant: https://github.com/brunch/brunch/wiki/Plugins . See for example source of the CoffeeScript plugin https://github.com/brunch/coffee-script-brunch/blob/master/src/index.coffee .
The ~/.cabal/config stores configuration which cabal-install uses. I wanted to do some hackery on it. (Specifically, having multiple GHC versions installed, I wish to have separate documentation indexes).
I couldn't, however, find any documentation about its' syntax or variables except for what is included in default file. Is there any documentation available?
Edit: I've stated the goal above, but let me add some details: If the same package (eg. GTK) is installed in two versions of GHC they end up in the same documentation index file. I wan't that local documentation index to be separate for each GHC installation. I believe it is possible in some way using documentation directory setting, but there has to be a variable for currently used GHC version. If there isn't one there might be some workarounds available, but I won't be able to say that unless I see the documentation.
This seems to work, although I've only tested it with one version of GHC:
documentation: True
doc-index-file: $datadir/doc/$compiler/index.html
install-dirs user
docdir: $datadir/doc/$compiler/$pkgid
With the other options left at the default, this generates documentation in .cabal/share/doc/<ghc-version>/<package-name>, and the index in .cabal/share/doc/<ghc-version>/index.html.
There appears to be very little online - not even the haddocks for the cabal-install code. So your best bet may be to puzzle it out from the source. cabal unpack cabal-install, or view the cabal-install repo online. Look at SavedConfig in Distribution/Client/Config.hs. As an example, it imports GlobalFlags from Setup.hs; the individual flags, eg globalCacheDir, are associated with their config-file syntax (which is also the command-line syntax) in the globalCommand function below, remote-repo-cache in this case.
You should also ask dcoutts in the #haskell channel on irc.freenode.net, in case he has new docs available.
Is it possible for single rpm package to belong to several groups?
In spec file you can set package group:
Group: System Environment/Base
What I need is to be able to set several groups for this package (like System|Util|MyCompanyName) - they would be like tags assigned to the package.
When the package is installed I want to query it like
rpm -q --group System
or
rpm -q --group MyCompanyName
and in both cases I should see my package (and others belonging to this group)
Edit:
Many packages may belong to MyCompanyName group, but only few may be installed. I need a way to differentiate our packages from linux system packages - I was planning to do it using the group name
I tried putting several Group: lines, but it only uses the last one. Everything after Group: seems to be taken as one string and I couldn't find a way to split them.
Another solution that I could think of is putting this stuff as PROVIDES and then to query
rpm -q --whatprovides System
but I don't like it this way.
Is there other way to accomplish the requested functionality?
The correct way to specify your company name is via the Vendor tag like this:
Vendor: Yoyodyne, Inc.
To get a list of packages by vendor you can run this command:
rpm -qa --qf '%{NAME} %{VENDOR}\n' | grep -v Yoyodyne
An RPM can only belong to one group. Furthermore, the allowable groups is defined by the distribution.
To find the valid groups for a particular distribution you must often run the package manager for that distro and look at the list.
RPM is not nearly as well defined as the Debian package format is. There seems to be no official or thorough documentation.
http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html
AFAIU, RPMs should belong to a single Group in RPM's GROUPS file or have Group unspecified. Cannot have more than one.
You might be able to define the groups at the repo-level instead of the package level using yum groups. Once you have your groups defined, you should be able yo use the 'yum groupinfo' command to see the packages in each group.
This is an old post but since it still shows up on Google;
Nowadays at least OpenSUSE uses the Group: field as a space-separated tags field instead of an hierarchial tree, so for SUSE packages you can simply space separate the tags you'd like your package to belong to.
See: https://en.opensuse.org/openSUSE:Package_group_guidelines for details.