I'm building a number of packages from one source package, I'd like one of my packages to depend on another package explicitly on the version that is being built and no-other - ie the current version being built.
Depends: original-package-min (= "what do I put here"),
I suspect there's an obvious answer, but I'm not finding it anywhere.
Background:
I'm trying to split a package into two, a minimal and a full version - something like this. The -min package exists because when building for a new distribution there can be circular (runtime) dependencies.
Package: original-package-min
Architecture: all
Depends: ${misc:Depends}
Description: Minimal version of original package
Useful when bootstrapping new or incomplete distributions
Package: original-package
Architecture: all
Depends: original-package-min (= "what do I put here"),
# lots of dependencies missing
${misc:Depends}
Description: Original package
Does what the original package does
Apparently the issue is knowing how to ask the right question. The right question here is "what can I put inside ${} in a debian control file"?
I expected to find the answer in the manual on Declaring relationships between packages, but I eventually found the reference to the reference to the reference here:
The fields here may contain variable references - their values will be substituted by dpkg-gencontrol, dpkg-genchanges or dpkg-source when they generate output control files. See Variable substitutions: debian/substvars for details.
To find the available substitutions simply run:
man deb-substvars
In this case the answer is
Depends: original-package-min (= ${binary:Version}),
It's possible ${source:Version} could also be appropriate according to the document they are the same, except in specific instances where they are different.
Related
When comparing different RPM files, I've noticed that not all of them expose the same header tags. So there must be some logic that activates/deactivates creation of some of them.
One example is the build time and host. I've stumbled upon two RPM specs. Neither mentions anything that looks at all like a specification or switch to provide the information. Still, one of them is generated with Build Time and Build Host fields, the other isn't (I am not permitted to post either one).
I am aware of the new _buildhost macro. The RPM version used to generate both is insufficient to use it. Both packages get created from a list of Sources, as far as I can see. The one that doesn't display the build information gets built using CMake/CPack, the other uses rpmbuild directly, that's the only information I have about serious difference.
Both are defined as Group: AddOn. So far, I haven't found any remotely definite resources about what groups are valid, or their meanings. Only thing I found was the list of deprecated groups in Fedora. I'd be more interested in a list of supported ones, but wasn't successful so far.
Resources I've found until now (omitting the pointless ones):
Max RPM Package Building Page, RedHat blog-ish tutorial, The RPM build guide, The actual RPM tags documentation, The RPM packaging guide
Unfortunately, none of the above provide the information I'm looking for.
"Give a man a fish" question: How can I suppress creation of Build Time or Build Host in rpm 4.11, be it in spec syntax or in usage of rpmbuild?
"Teach a man how to fish" question: Is there any documentation about what header tags get created with which settings?
You can use Mock for building rpm (recommended anyway). and use config_opts['hostname'] = 'my.own.hostname'.
Mock will call sethostname() in the chroot.
This is the only way how to do it AFAIK.
rpmbuild should honor SOURCE_DATE_EPOCH - but I never used it.
You can set environment variable using:
config_opts['environment']['SOURCE_DATE_EPOCH'] = 'foo'
I have found several interesting links talking about a CPack generator for FreeBSD.
I would like to generate FreeBSD packages; however, whenever I attempt to generate TXZ archives (as directed by the instructions), the generated package isn't compatible with the pkg utility on FreeBSD. They miss the manifest file.
Obviously, CPack is generating raw archives, not pkg-ready archives. I assume I must be missing a step.
However, none of the links above talk about any such step.
Therefore,
How can I tell CPack to generate a FreeBSD-ready package?
(Original author of that code here)
So, there's two things in play here:
you need to be on FreeBSD (so that you have libpkg, which is needed to do the building)
you need to build the devel/cmake package with OPTIONS CPACK (which is not the default)
So:
cd /usr/ports/devel/cmake
make configure and select CPACK
make && make install
Then #Tsyvarev's comment will be the right answer. For the record, the support was deemed experimental, the library API unstable, and the pkg authors have asked me to re-vamp the code to use the current libpkg API so they can drop the old one. Time, though, is the limiting factor.
Using the search I already found some great answers to similar questions, but still I am not sure if I understood it correctly.
From these answers I learned that dependencies are required to run the application while devDependencies are only required while developing (like unit tests).
But how about this: My application depends on jQuery, but during a build step (with the help of my devDependencies), everything is bundled into one file. In this case, should I list jQuery as dependency or as devDependency?
To make my point more clear take a module like this:
define(['jquery'], function($) {
// use jQuery in this module
})
Later on, this module will be compiled into somehing like application.build.js which then contains this module and the jQuery dependency.
Since the end result is the same, there doesn't seem to be a definite rule here, but I found a couple of discussions on the matter:
If you're building an application
https://github.com/webpack/webpack/issues/520
A browser app built by [insert build tool/bundler] has no runtime node dependencies, and thus all frontend dependencies should be listed as devDependencies. The dependencies vs devDependencies naming convention stems historically from node being a server side package manager (...) It is as far as I can tell harmless to list frontend dependencies under dependencies, but it is wrong.
(...) as a general recommendation for everyone, move everything into devDependencies until it is actually needed under dependencies.
If you're building a library:
https://github.com/inuitcss/inuitcss/issues/225
In many frontend projects, all code served to the browser is compiled, there are no runtime dependencies. This would mean that there are no dependencies, only devDependencies – all dependencies are included in the build done during development.
One could also argue that dependencies are required for development as well, so it would be okay to list everything unter dependencies.
I think the fact that we have the optional distinction indicates a reasonable way to use them. It makes sense (to me) that the dependencies designation would represent the 'minimum viable' code to use and as an indicator of what's nonessential for something to work.
As I see it, anything that goes on to become part of the production code is a dependency.
Epilogue
Personally, I agree more with the last quote. It makes sense that dependencies tells us what the application code needs to run, and devDependencies what the developer needs to build/deploy/whatever the application/library.
One caveat though is that if someone npm installs your library to use the bundle as a module in their own application, they will download a lot of dependencies they don't actually need.
Is there any command in the Perl6 Rakudo distribution which lists all the installed modules on the system?
I tried the following command:
p6doc NativeCall
and get the following error :
===SORRY!===
Cannot invoke this object (REPR: Uninstantiable)
but when I write a p6 file which contains :
use NativeCall;
it compiles with no problem.
How can I browse for such a Perl 6 module (like perldoc for Perl 5) and how can I list all the installed Perl 6 modules?
The module manager is zef, not p6doc
p6doc ... is meant for managing (searching/displaying) documentation not for managing modules.
zef should already be installed on your system. If not, install it from its github repo.
The error message you got from p6doc suggests something is borked in your installation. I think it's most likely something not worth chasing for another month so I suggest you ignore it for a month, make sure you're running an up-to-date Perl 6 distribution (eg the latest Rakudo Star), and then, if it's still around, consider speaking up about it on #perl6 and mentioning this closed bug report.
Hth.
zef is your (best) friend in Perl6 universe.
zef --help
will give you any information you have ever wish aboutZef and how to use it and therefore any information about any installed modules.
zef list --installed
If you are looking for a specific module, you can use:
zef search module
in the list returned, you'll see in the first lines:
Zef::Repository::LocalCache... Module
...
which gives you a list of installed modules related to your question.
I'm trying to convert our build system at work over to cmake and have run into an interesting problem with the RPMs that it generates (via cpack): It automatically adds all of the dependencies that it thinks your RPM has to its list of required libraries.
In general, that's great, but in my case, it's catastrophic. Unfortunately, the development packages that we build end up getting installed with one our home-grown tool that uses rpm to install them in a separate RPM database from the system one. It's stupid, but I can't change it. What this means is that all of the system libraries that any normal library will rely on (like libc or libpthread) aren't in the RPM database that is being used with our development packages. So, if an RPM for one of our development packages lists system libraries as being required, then we can't install it, as rpm will think that they're not installed (since they're listed in the normal database rather than the one that it's being told to use when installing our packages). Our current build stuff handles this just fine, because it doesn't list any system libraries as dependencies in the RPMs, but cpack automatically populates the RPM's list of required libraries and puts the system libraries in there. I need a way to stop it from doing so.
I tried setting CPACK_RPM_PACKAGE_REQUIRES to "", but that has no effect. The RPM cpack generates still ends up with the system libraries listed as being required. All I can think of doing at this point is to copy the RPM cpack generator and hack it up to do what I want and use that instead of the standard one, but I'd prefer to avoid that. Does anyone have any idea how I could get cpack to stop populating the RPM with required libraries?
See bottom of
http://www.rpm.org/max-rpm/s1-rpm-depend-auto-depend.html
The autoreqprov Tag — Disable Automatic Dependency Processing
There may be times when RPM's automatic dependency processing is not desired. In these cases, the autoreqprov tag may be used to disable it. This tag takes a yes/no or 0/1 value. For example, to disable automatic dependency processing, the following line may be used:
AutoReqProv: no
EDIT:
In order to set this in cmake, you need to do set(CPACK_RPM_PACKAGE_AUTOREQPROV " no"). The extra space seems to be required in front of (or behind) the no in order for it to work. It seems that the RPM module for cpack has a bug which makes it so that it won't let you set some its variables to anything shorter than 3 characters long.
To add to Mark Lakata's answer above, there's a snapshot of the "Maximum RPM" doc
http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-auto-depend.html
that also adds:
The autoreq and autoprov tags can be used to disable automatic processing of requirements or "provides" only, respectively.
And at least with my version of CPackRPM, there seems to be similar variables you can set e.g.
set(CPACK_RPM_PACKAGE_AUTOREQ " no")
to only disable the automatic dependency processing of 'Requires'.