Going through a package name change, so all my new packages (eg newlib, newlib-devel, etc) obsolete and conflict with the old packages (eg oldlib, oldlib-devel).
The -debuginfo package however is automatically created, is there a way to add obsoletes and conflicts fields to the package without disabling its automatic creation (%define debuginfo %{nil}) and creating the debuginfo package "by hand"?
I don't know if you solved your problem but for me it was enough to add *-debuginfo package to Obsoletes field of my RPM spec. Otherwise I had conflicts when trying to update the old package.
Example:
Obsoletes: oldlib oldlib-debuginfo
Cheers,
Tomasz
Related
My OpenAPI (v3.0.0) YAML spec has references to other schemas. These schemas are in files named like gender.v1.yaml.
The generated models (for language = kotlin or kotlin-spring) have class names such as Genderv1.
This seems logical to me, however this is a recent change and I'm not sure what is causing this switch. Previously the class name from the same file used to be Gender.
Furthermore, the same spec and openapi-generator-cli version on other systems such as our CI, generates Gender i.e. without the characters after the ..
This leads me to believe that there is something local that is causing this issue.
I was trying to use a lower version of openapi-generator on my Mac, by installing via npm and performing a openapi-generator-cli version-manager set 5.3.1 for e.g.
Previously I had openapi-generator installed via brew with a version of 5.4.1.
I've tried uninstalling, going back and forth between npm, brew and generator versions, to no avail.
I have access to a conan repository which contains the same packages in two different channels, namely zlib/1.2.11#conan/stable and zlib/1.2.11. In my project, I'm using a conan package which requires zlib/1.2.11 and I want to add another package that requires zlib/1.2.11#conan/stable.
Consequently, I receive the following conflict: To fix this conflict you need to override the package 'zlib' in your root package.
However, I have to work with the given packages and cannot change the dependencies. Is it possible to link zlib/1.2.11#conan/stable to zlib/1.2.11?
It is not possible to create an alias using conan alias as both packages are available in the repository. Can I use conan remove to remove one of the packages only locally without changing the repository such that I can create an alias?
I have a CMake project to build multiple shared libraries and tools, most of these under subdirectories:
add_directory(libFirst)
add_directory(libSecond)
add_directory(myTool)
# etc...
The install(TARGET "someTarget" COMPONENT "someTarget" ...) rules are in the respective subdirectory/CMakeLists.txt files.
I would like to generate Debian packages for all of these using a make package command from the build directory. I have CPACK_DEB_COMPONENT_INSTALL set to ON.
The problem I'm facing, is that not all of the targets have the same VERSION and/or SOVERSION. For example, libFirst is at version 1.0.0.0 and libSecond is version 4.3.0.0. This means that the generated packages should also have different version, but the only way I've found to specify the version is to specify the CPACK_PACKAGE_VERSION_MAJOR, CPACK_PACKAGE_VERSION_MINOR and CPACK_PACKAGE_VERSION_PATCH variables (and perhaps the internal CPACK_PACKAGE_VERSION variable), which set the version for all generated packages.
Is there a way to set package versions per-component, for example by setting some variables similarly to the other CPACK_COMPONENT_<COMPONENT>_* or CPACK_DEBIAN_<COMPONENT>_* variables?
I don't think this is possible at the moment but I have created a merge-request (https://gitlab.kitware.com/cmake/cmake/merge_requests/2305) which provides this functionality.
I hope it will get approved but in the meantime you can locally change your CPackDeb.cmake as shown in this diff: https://gitlab.kitware.com/cmake/cmake/merge_requests/2305/diffs. The default location of that file is in /usr/share/cmake/Modules/CPackDeb.cmake.
Is there any way to rename an NPM module that has already been published? I want to change the name of my module to more accurately match the API it exposes but would not like to leave people who have already installed it in the lurch.
There isn't any exposed way to do that. When I've encountered this in the past the approach I took was:
npm deprecate %ProjectName%#"<=put-latest-version-here" "WARNING: This project has been renamed to %NewProjectName%. Install using %NewProjectName% instead."
npm Deprecate instructions
In simple words no you can't. But npm provides you a different solution called npm deprecate.
What it does is it marks a particular version or version ranges of that package as deprecated. So next if someone tries to install this package they get a warning package deprecated along with your custom message, in which you can easily specify your new package name.
Usage:
npm deprecate my-package-name#"< latest-version" "your message"
Your message can be any thing like:
WARNING: This project has been renamed to your-new-package-name. Install using new-package-name instead.
In less than 24 hours i ran following command to delete wrong package.
npm unpublish <wrong package name> --force
From the documentation:
Registry data is immutable, meaning once published, a package cannot
change. We do this for reasons of security and stability of the users
who depend on those packages.
However newly published packages - within 72 hours - can be unpublished by running:
npm unpublish <package_name> -f
This will remove the package from the NPM registry if it was published less than 72 hours ago. Then you can change your package's name and publish it again.
Caution: You need to wait 24 hours if you try to republish package
with the same name
Someone has built a handy little npm plugin for doing this easily 😊
https://www.npmjs.com/package/#tiaanduplessis/pkg-rename
Install the package using npm -g install #tiaanduplessis/pkg-rename
Rename your npm module in the package.json file and save it
run pkg-rename old-package-name
From the documentation:
This will get the latest version of the old package from npm and deprecate this and all previous published versions with a message:
WARNING: This project has been renamed to new-package-name. Install using new-package-name instead.
You can also add the --publish flag to publish the new package name as part of the same action.
pkg-rename old-package-name --publish
Remember, rename the package in package.json first, then run the pkg-rename command.
I once was in this situation. I published a package with the name bowser-or-node instead of browser-or-node.
There's no way to rename a package, you have to deprecate and publish a new package.
Although there's one other option. If you just published your package (less than 24 hours from time of publish) and if you're sure you're okay with deleting the package and publish a new one with the right name, you can go ahead and do it. But NPM won't allow you to delete the package once it's been 24 hours since the time of publish.
Fortunately I figured out that I published with the wrong name in less than 20 minutes. So I just deleted and published again with a new name.
Something marvelous just happened to me: I managed to rename a package. It was originally known as stdout-renderer, but I changed every possible occurence of the name, and republished it after having deprecated the original and voila it shows up under its new name (cli-artist) undeprecated in the newly updated list. I'm not sure which field to change, but I would imagine it be in package.json because that's the only one where the casing matched in my case.
hope that helps!
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'.