| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When a pkg certificate is in it's last 30 days before expiration, the
pkg tools emit a warning message so you can get a new certificate for
some operations. The 'latest' method issues a 'pkg -Hn <package>' which
trips this warning message, but the message was unexpected and 'latest'
would raise, failing the catalog application.
This commit simply ignores such certificate expiration warnings.
While I was in there, I split a very compact line of code across a couple
lines and added some spaces, in the name of readability.
|
|
When executing the list command to filter virtual packages (when
allow_virtual is false or nil), the yum package provider was not passing
down the install options to the list command. For users passing options
like --enablerepo, this prevents the packages from being discovered and
the list command fails.
The fix is to properly pass down the install options when executing the
list command.
|
|
fiddyspence/feature/2945/warning_on_windows_package_source
(PUP-398) Windows package provider source munging and test
|
|
Adding munge and slashreplace method to windows package provider
to ensure successful installation of packages. Validation in the
type validate() not possible because we haven't chosen a provider
at that point. Outputs debug as a means of notifying the user that
the source has been changed.
|
|
adrienthebo/fixup/master/pup-2871-install-uninstall-options-pacman
Fixup/master/pup 2871 install uninstall options pacman
|
|
These methods should not be called by any outside class; this commit
makes them private and removes the tests that invoke them directly.
|
|
In the same manner as 9137faf uninstall_options were being appended as a
nested array value; this commit changes the uninstall method to
concatentate options to the array.
|
|
Before this commit, install_options were passed as a nested array to
pacman/yaourt. This commit changes that to concatentate the values
with the argument vector.
|
|
|
|
|
|
- Windows::Error no longer exists and the ERROR_FILE_NOT_FOUND
constant is part of the Puppet codebase now.
- Catch appropriate error in package specs
- Remove windows-pr, win32-api and windows-api from gemspec
|
|
Without this patch, a user unfamiliar with the pacman provider might write
attempt to add flags to install and uninstall, not knowing that they will fail.
This patch adds support for these two flags to ensure a more cohesive experience
across puppet.
|
|
- Somehow there were still some remaining constants referencing
Windows:: which is part of windows-pr gem. Most are already
defined locally as of the code being ported to FFI. Ensure that we
use our internal constant definitions rather than those from gem:
Puppet::Util::Windows::AccessControlEntry::CONTAINER_INHERIT_ACE
Puppet::Util::Windows::AccessControlEntry::OBJECT_INHERIT_ACE
Puppet::Util::Windows::AccessControlEntry::INHERIT_ONLY_ACE
Puppet::Util::Windows::File::STANDARD_RIGHTS_ALL
Puppet::Util::Windows::File::SPECIFIC_RIGHTS_ALL
Puppet::Util::Windows::File::FILE_ALL_ACCESS
Puppet::Util::Windows::File::FILE_GENERIC_READ
Puppet::Util::Windows::File::FILE_GENERIC_EXECUTE
- Add new constants to Puppet::Util::Windows::Error
ERROR_FILE_NOT_FOUND
ERROR_ACCESS_DENIED
|
|
- use .tgz as the package extension
- complete 'provider features' and sort lines
|
|
(PUP-1069) Implement feature :upgradeable for OpenBSD package provider.
|
|
- FFI GetACP
- Remove requirement on gem windows-pr by removing 'windows/national'
- Moved require for windows/registry into windows platform specific
- Added module definition to satisfy MSI/Windows Package
|
|
* upstream/stable:
(PUP-2182) Fix yum and zypper providers virtual_package feature.
|
|
The yum and zypper package providers were installing virtual packages even when
allow_virtual was default or set to false.
For yum, the fix is to do a "yum list" command before doing an installation whenever
allow_virtual is not true. The list command will fail on virtual
package names. This will prevent the package from being installed as
expected and is only performed if a version is not ensured, since
virtual packages cannot be installed by version.
For zypper, the fix is to pass the --name option to zypper if not
allowing virtual packages and a version string was not ensured.
|
|
In 3.5.x, the yum package provider changed to accept virtual package
names (packages that provide other package names).
That change in behavior caused some undesirable side-effects. As we did
not give users fair warning that this behavior was changing, we have
decided to change the yum provider back to only accepting "real" package
names by default.
To keep the support for virtual package names, a "virtual_packages"
feature has been implemented on the package type and supported on the
yum package provider. The feature adds the "allow_virtual" parameter
that controls whether or not virtual package names will be allowed for
install/uninstall.
For now, the default value for this parameter will be false to restore
the previous behavior. However, a deprecation warning will be issued to
let users know that the default will eventually be changed to true.
Users can prevent the deprecation warning by explicitly setting the
parameter to either true or false.
|
|
(PUP-2182) Add virtual_packages feature to package type.
|
|
(PUP-2311) OpenBSD uninstall broken when multiple uninstall_options give
|
|
In 3.5.x, the yum package provider changed to accept virtual package
names (packages that provide other package names).
That change in behavior caused some undesirable side-effects. As we did
not give users fair warning that this behavior was changing, we have
decided to change the yum provider back to only accepting "real" package
names by default.
To keep the support for virtual package names, a "virtual_packages"
feature has been implemented on the package type and supported on the
yum package provider. The feature adds the "allow_virtual" parameter
that controls whether or not virtual package names will be allowed for
install/uninstall.
For now, the default value for this parameter will be false to restore
the previous behavior. However, a deprecation warning will be issued to
let users know that the default will eventually be changed to true.
Users can prevent the deprecation warning by explicitly setting the
parameter to either true or false.
|
|
|
|
|
|
|
|
Currently the gem provider will match gemname$, for example with bundler
this will return quite a long list of anything ending with bundler. When
a match returns a longer list, it will actually connect and try to pull
the latest gem again, thus increasing the WAN usage and rubygems.org
usage when not necessary.
The proposed fix adds a ^ in front of the name var to ensure it begins
with the gemname.
|
|
When a package resource is ensured => latest, the specific version
available will depend on what yum repositories are enabled and disabled.
Commit a4abf13d3 added the ability to pass arbitrary options to install
and update commands which allowed users to specify the --enablerepo and
--disablerepo options, but these flags would not be respected when the
latest package version was used. This meant that the latest version
found and the version that could be installed with the --enablerepo and
--disablerepo flags might differ, causing all sorts of bad things to
happen.
This commit resolves this issue by making the version query aware of
these flags. When a package checks for the latest version available, it
passes all repositories enabled and disabled to the update query.
Whenever an update query is made for the first time with a combination
of repositories that output is stored, so that only query for a given
combination of repositories is made.
Unfortunately, this change still relies on yumhelper to do the actual
querying. In the long run it would be good to use `yum check-update`
instead of the complex helper script so that we can actually test and
verify the code responsible for querying packages.
|
|
In the previous implementation of yum .prefetch, package providers were
loaded and then the yumhelper.py script was used to determine the latest
versions available for all installed packages. While this worked for
simple cases, trying to support multiple combinations of enablerepo and
disablerepo flags makes this grossly more complex. In addition this
information is not needed at prefetch time, and testing the behavior in
prefetch gets messy.
This commit extracts the latest version query from the prefetch method.
It moves the logic to a method that does the actual querying and lazily
loads that data to keep the same run speeds. When multiple combinations
of enablerepo and disablerepo are added this information can be loaded
in the same fashion.
|
|
Moving the implementation of join_options into the base package provider.
This gives a consistent behavior between all package providers that support install_options.
|
|
Fixing the apt package provider spec so that the resource isn't entirely
mocked and returning 'asdf' for every property. Modeling the spec after
the yum package provider spec to accomplish that.
Adding install_option example that tests for hash.
|
|
Fix apt package provider install options to support hash in addition to
arrays and strings. This makes it consistent with other package
providers.
Add spec examples to test install options.
|
|
* upstream/stable:
(PUP-1937) Revert changes to with_version
(PUP-2039) Fix rpm package provider usage of --whatprovides.
|
|
The fix for PUP-897 (commit ecb761e24a) introduced always passing
--whatprovides to rpm when querying for packages. This breaks querying
for packages that have architectures specified, e.g.
'vim-enhanced.x86_64'.
The proper way to do this is to first query without --whatprovides and
see if rpm finds a package by the given name. If rpm fails to find a
package, fallback to using --whatprovides to support querying for
virtual package names.
|
|
The spec had an example which was expecting a nil
install_options by checking the 6th element in an array.
With the change to not append the install_options
unless specified, the example was passing but the
functionality no longer matched the example.
Changing the example to ensure 5 elements were
passed to execute instead of the previous 6.
|
|
* pr/2429:
(PUP-620) Add spec examples for yum install_options.
(PUP-620) Limit gem install_options to install only.
(PUP-620) Add install_options to gem provider
This closes GH-2429.
|
|
Checks nil install_options.
Checks plain values and hash key-pairs.
|
|
(PUP-748) Fix the zypper package provider support for install_options.
|
|
* pr/2414:
(PUP-1769) Don't pass nil through to provider command
(Maint) Convert test to use real resource objects
(PUP-1769) Update yum specs with install_options
(PUP-1769) Use join_options command
(PUP-1769) Changing the has_feature to a one-liner
(PUP-1769) yum provider takes install_options
Closes GH-2414
|
|
Previously, if `install_options` was not specified, then we would
pass a nil value through to the `yum` command. While this would work, we
don't document that nil's are acceptable arguments.
This commit ensures we only pass in non-nil `install_options`.
|
|
Use real yum package resource objects
|
|
Specs now take into consideration the install_options parameter, with
both singletons and key-value pairs.
|
|
Remove expected nil when calling execute without install_options.
Add specs for install_options as a hash, array, or string.
|
|
The yum provider now supports install_options.
|
|
- Added a test for the installedgroups function
- Fixed behaviour of instances function
- Pointed a test for code that has moved at the new function
|
|
|
|
Some providers that inherit from the rpm provider, such as the yum provider, do
a query after installing a package. If the package is specified by a virtual name,
the yum provider installs the package successfully, but the base rpm provider
implementation fails to query the installed package. This causes a confusing
"could not find package" error even though the package was installed.
Passing the '--whatprovides' option to rpm when performing a query instructs rpm
to locate packages that provide the given virtual name. This enables child providers
to install by virtual package name without errors.
|
|
provider.
GH-2023 included a change that added a version onto the resource. However, since
a provider was not declared, it used the system's default provider.
Because of this, running the spec on a system with a default provider that doesn't
supoprt the versionable feature would cause the spec to fail.
The fix is to set the provider on the resource and move the ensured version to the
particular test case.
|
|
Implemented the upgradeable and versionable features on the pkgin package provider so
that packages can use `latest` and version numbers in the ensure property.
|
|
Prior to this change the defaultprovider for package was implicitly cached
in both package_spec.rb and msi_spec.rb (just by checking it). This represented
spec "leakage" which could result in downstream spec failures on subsequent
tests which accessed defaultprovider. E.g. this sequence failed:
be rspec spec/unit/provider/package/msi_spec.rb spec/unit/type/package_spec.rb
This change clears the defaultprovider for package after caching it for
both these two spec tests.
However, there are a lot of uses of defaultprovider in spec tests, so we may
want a more general solution.
|
|
This reverts commit a20b16bb70446d43c51340f72c821fc3a93c7cb6, reversing
changes made to 00579976264da4b2b8492bb664291b9ba0d5987c.
Unfortunately this change introduced a number of problems that need to
be addressed before this code can be released.
1) The yum provider is always holdable
The package type detects the ability to hold packages based on the
presence of the #hold method. Even though there is a guarding clause
around the `has_feature :holdable` in the provider it's bypassed when it
fails since the provider defines the #hold method.
This ties into:
2) Holding a package without the yum-plugin-versionlock raises errors
Since the plugin isn't available but the provider looks like it's
holdable, applying a resource like:
package { 'bash':
ensure => held,
}
results in a backtrace since `yum versionlock` returns 1, and a
Puppet::ExecutionFailure is raised.
3) Held packages are not idempotent
When the yum versionlock plugin is installed, the resulting resource is
not idempotent because the ensure value is always being changed from
$version to 'held':
[root@localhost puppet]# puppet resource package bash ensure=held
Notice: /Package[bash]/ensure: ensure changed '4.1.2-15.el6_4' to 'held'
package { 'bash':
ensure => '4.1.2-15.el6_4',
}
[root@localhost puppet]# puppet resource package bash ensure=held
Notice: /Package[bash]/ensure: ensure changed '4.1.2-15.el6_4' to 'held'
package { 'bash':
ensure => '4.1.2-15.el6_4',
}
|
