I've accidentally uploaded a faulty distribution and tried to reupload it right away, but cabal replied with:
This version of the package has already been uploaded.
As a matter of policy we do not allow package tarballs to be changed after a
release (so we can guarantee stable md5sums etc). The usual recommendation is
to upload a new version, and if necessary blacklist the existing one. In
extraordinary circumstances, contact the administrators.
Okay, I've incremented the version and uploaded the correct distro, but now I am interested in blacklisting the faulty release, as suggested. However there is no notion about how to do that anywhere whatsoever. How to do that? And what do they actually imply by the term "blacklisting"?
Go to your package page on Hackage. Scroll down to Maintainers' corner and click on edit package information. Then you'll have an option to click on Preferred versions.
This page allows you to specify version ranges or deprecate individual package versions.
Deprecated versions won't be completely gone, but cabal-install will try to respect the preferences when trying to resolve dependencies.
Related
Many Cygwin's packages have no maintainer, is it still revelant to use Cygwin ?
I would like to update ruby or ansible package to the last version, how can I do that ?
Thanks
Package maintainers are volunteers.
Anyone can offer him/herself for the job.
Documentation
https://cygwin.com/packaging-contributors-guide.html
Mailing list for discussion about Maintainers
https://cygwin.com/mailman/listinfo/cygwin-apps
If you want to be a maintainer you must subscribe to the Cygwin mailing lists. All discussions about maintaining packages are there, and you will be required to post your credentials (i.e. public key) there in order to upload updated packages. Note that some orphan packages became so because the previous maintainer needed to reduce their workload.
Once you are subscribed, just ask to take over an orphaned package, upload your credentials, install the source package, make necessary changes, and upload the new package. It sounds easy, but you might want to build the package and make sure it runs all tests before asking to be the new maintainer.
Note that there may be others who have tried to update a package, and encountered blocking problems. Those will be discussed in the mailing lists, which you can search.
On the website of Debian, it's written about point releases:
They usually incorporate the security fixes released until the time of
the update and fixes for grave bugs in the current release.
If I correctly understand, that means only minor updates can occur in the packages of the current stable version, right?
In other words, I want to know if a binary who depends of a library in a specific version (libmicrohttpd.so.12 for instance) will stay compatible in the next point releases of Debian.
Yes, but it is very seldom.
In general you are right, the point releases should not change existing API and ABI.
But there could be problems on doing that: security changes would require a lot of work, and upstream will do only for the new version. In such cases the version will be dump. But this is very seldom: it would need a security bug which effect the fundamental design of a library (not just some coding error).
In any case the old version will remain on archives, and you can keep it (so that it would not be automatically removed), so that you can still use, hopefully with relevant safe guard.
We build our installs\releases using Install Shield. I have come to a situation where we have a patch that cannot be upgraded by a release with a higher version number, that is missing components included in the patch.
After releasing a full minor release (i.e. 7.2.0) we released a patch on a previous full minor release (i.e. 7.1.12).
The Patch 7.1.12 had files and components added that do not exist in 7.2.0. The patch is not uninstallable.
It is now impossible to upgrade 7.1.12 to 7.2.0 because of the missing components. Some customers specifically want to upgrade to 7.2.0 and not a later version (7.3.0) where the components can be added to fix the issue.
Short of uninstalling 7.1.12 and then installing 7.2.0 I couldn’t find any solution to fix.
Is there any way around this? Can we build a 7.1.13 as a bridge to somehow fix the mistake. Or use an argument when installing 7.2.0 to get around this.
I looked around the registry and I am trying to figure out if it is possible to remove the components through the registry.
I tried deleting the component entries in the registry. that didn't do it.
If I delete the product entry in the registry that works - but it must be overkill.
I also tried deleting the patch msi from C:\Windows\Installer but that didn't do it.
There must still be a way to unlink the component from the feature in the registry without deleting the entire product.
It sounds like you're trying to do a series of Minor Upgrades, with at least 7.1.12 delivered as a patch. Using minor upgrades imposes various limitations; anything that requires you to Change the Product Code must be avoided. In your case, note that adding components is allowed, but not the reverse:
The update can add a new component to a new or an existing feature.
The product code must be changed if any of the following are true for the update:
A component is removed from an existing feature.
In short, any modifications to the feature-component tree, other than the addition of new ones, is going to require changing the product code, and thus a Major Upgrade. Major upgrades perform an uninstallation behind the scenes, and thus are less restrictive about the changes they are allowed to deliver.
You have two options:
Use a major upgrade, or some other means of uninstalling the old installation before installing the new version. If possible, this is what I would recommend. Using minor upgrades often adds more difficulty than benefit (though your needs may differ).
Maintain the new components in your newer versions. Note that you do not necessarily have to maintain the resources within them:
The update can add, remove, or modify the files, registry keys, or shortcuts of components that are not shared by two or more features.
But you will have to make additional changes to account for the changes to the resources. In your case, this probably will require additions to the RemoveFile table, and may be best served by "puncture component" pattern.
Spelunking through the registry for a workaround that modifies Windows Installer's bookkeeping is a bad idea. It may work, it may appear to work, or it may not work at all. In no case is it supported.
If both versions 7.1.12 and 7.2.0 are already publicly released, you're in a rough spot. I think your best bet there is to re-release 7.2.0 with a new product code and version, e.g. a 7.2.1 major upgrade. You can advise your end users that those already at 7.2.0 don't need to install it.
I have a ST3 package hosted on GitHub and available through Package Control. It has been superseded by a new package that I wrote, but I keep getting bug reports for the old one since many people are still using it.
What is the correct way to remove the option to install the original package from package control, and ideally from GitHub if possible, without messing anything up for users who currently have the old package installed?
Specifically, will submitting a pull request to Package Control to remove the old package, and/or deleting the old package's github repo, cause the old package to disappear from people's Sublime Text?
I strongly suggest reading through the package developer docs, especially the section entitled Renaming a Package, as they explain everything in detail. Essentially, the easiest path would be to following the directions for renaming a package, and at the same time change the URL to your new Github repo. This way, the old packagecontrol.io page will no longer be available, and upon restart users of the old package should be upgraded to the new one.
I'd also recommend reading through the Package Control Channel's issues to see if this issue has come up before. Worst case scenario, you submit your PR and it gets rejected for some reason, but they'll explain what you need to do differently.
When browsing the packagist.org repositories you see packages with these version numbers e.g. If you look at the Phpunit repo
There are a few instances
4.5.x-dev
4.3.x-dev
4.2.x-dev
Do these packages contain the current work the developers are performing towards basic updates, security and bugfixes etc on an otherwise basically stable package?
These are the dev branches. These are unstable and contain bug fixes, etc. This will eventually be released as 4.5.8 for instance (if the library is still supported).
You can get it by using 4.5.x-dev or 4.5.*#dev as version constraint.