Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add full VERSIONs / SONAMEs to our libraries #273

Merged
merged 2 commits into from Oct 19, 2016

Conversation

Projects
None yet
8 participants
@v4hn
Copy link
Member

commented Oct 9, 2016

This has been on my mind for quite some time and I consider the discussion (and hopefully merge) of this request as a blocker for the upcoming indigo and kinetic releases.

This request is still incomplete and only adds versions to moveit_core's libraries. I would like to include moveit_ros in this change too. However, I want to start the discussion, so please give your opinion.

As a result of this request the libraries do not install as libmoveit_xyz.so anymore, but as libmoveit_xyz.so.${MOVEIT_VERSION} and provide libmoveit_xyz.so as a symlink pointing to the versioned file.

Because this sets each library's SONAME to the full version, this enforces that every binary links with the versioned library file from now on and has to be relinked with each new release of MoveIt!.

An alternative would be to set the SONAME to $MAJOR.$MINOR and ignore the patch version. But because we currently stay with one $MAJOR.$MINOR number within each ROS distribution, we had (and likely will have) ABI changes in the $PATCH version releases too.

The reason for this commit is that it is practically impossible to maintain full ABI compatibility within each ROS distribution and still add the the features/patches the community asks for. This has resulted in more than one ABI-incompatible MoveIt! release in the recent past within a ROS distribution. Because the libraries have not been versioned up to now, there was no way to indicate the incompatible changes and users who did not rebuild their whole workspace with the new release encountered weird and hard-to-track segfaults or broken behavior.

The main alternative I see for us at the moment is to set hard-coded versions for each library. Then, whenever we do a release and changed the ABI of individual libraries within MoveIt, we could increase the version of each of these libraries independent of each other. As a result, only binaries that link against libraries that actually changed their ABI would have to be rebuild with a new release.
This adds quite a bit of overhead to the release process and also introduces a variety of library versions within a single MoveIt version over time that will probably confuse new users. I believe the alternative I propose in this request is superior.

@jspricke I discussed the need for SONAMEs with you quite a bit, so it would be great if you could have a look at it too.

@davetcoleman davetcoleman referenced this pull request Oct 9, 2016

Closed

Kinetic Release #18

19 of 19 tasks complete

@v4hn v4hn referenced this pull request Oct 9, 2016

Closed

Initial Indigo release from ros-planning/moveit repo #100

15 of 15 tasks complete
@de-vri-es

This comment has been minimized.

Copy link
Contributor

commented Oct 10, 2016

+1. If we have to break things, the louder and earlier it happens during the build, the better.

As for using using the moveit version or manually bumping on ABI breakage: it sounds like the manual method is too easy to forget. I'd prefer to err on the safe side even if that means unnecessary rebuilds. So unless someone thinks they can put in the effort for reliably bumping sonames on releases with ABI change, my preference is for using the moveit version.

As for including the patch number or not: it would be nice if it can be left out. That should be fine as long as we bump minor version when ABI compatibility breaks. The only problem with that is the indigo/jade/kinetic releases conflicting with each other, but I think that is a different discussion. But as long as we break ABI in patch-level releases we should include it.

@v4hn

This comment has been minimized.

Copy link
Member Author

commented Oct 10, 2016

On Mon, Oct 10, 2016 at 12:49:26AM -0700, Maarten de Vries wrote:

As for including the patch number or not: it would be nice if it can be left out.
That should be fine as long as we bump minor version when ABI compatibility breaks.

Yes and yes.

The problem is that we do (and want to) backport new features and ABI changes to older branches, but will not backport API changes.*
Thus we would need to bump the minor version of stable branches separately from the most current branch and that conflicts with our current "different minor versions for different branches" policy.
I do not consider it an option to use different major versions for each branch instead.


*This, by the way, somewhat relates to the proposal to have a "master" branch that should work across the supported ROS distributions/Linux distributions.

add_library(${MOVEIT_LIB_NAME}
src/background_processing.cpp
)
add_library(${MOVEIT_LIB_NAME} src/background_processing.cpp)

This comment has been minimized.

Copy link
@davetcoleman

davetcoleman Oct 11, 2016

Member

while its not worth changing, I prefer the previous format because it makes adding more files to the library list cleaner in the future

src/background_processing.cpp
)
add_library(${MOVEIT_LIB_NAME} src/background_processing.cpp)
set_target_properties(${MOVEIT_LIB_NAME} PROPERTIES VERSION ${${PROJECT_NAME}_VERSION})

This comment has been minimized.

Copy link
@davetcoleman

davetcoleman Oct 11, 2016

Member

Out of curiosity, where is the value of ${${PROJECT_NAME}_VERSION} set?

@davetcoleman

This comment has been minimized.

Copy link
Member

commented Oct 11, 2016

Thanks @v4hn!

+1 to including the patch version in the sonames, we release so rarely I don't think the rebuild time is that important and I do forsee us still breaking ABI between patch versions due to the way our versioning is done between I/J/K. I also like having the sonames the same as the versions, to ease maintenance. I'd like to see this PR expanded to all of MoveIt!, as @v4hn intends.

@wjwwood perhaps you have any wisdom on this change for moveit?

@jspricke

This comment has been minimized.

Copy link
Contributor

commented Oct 12, 2016

+1 from me, would be really great to have it :).

@v4hn

This comment has been minimized.

Copy link
Member Author

commented Oct 12, 2016

On Tue, Oct 11, 2016 at 11:49:31AM -0700, Dave Coleman wrote:

Out of curiosity, where is the value of ${${PROJECT_NAME}_VERSION} set?

In the guts of catkin_package() where it is extracted from the package.xml.

@davetcoleman

This comment has been minimized.

Copy link
Member

commented Oct 16, 2016

@v4hn can you finish this PR so we can get Kinetic out of the door?

@v4hn

This comment has been minimized.

Copy link
Member Author

commented Oct 17, 2016

I just came back to my keyboard yesterday.
I'll try to get through my pending todo list fast.

@rhaschke

This comment has been minimized.

Copy link
Collaborator

commented Oct 17, 2016

I like the idea of introducing sonames in general. However, I think we missed some important points:

  1. Usually, supporting sonames should include support for several installed lib versions in parallel. However, as far as I know, this is not possible with the ROS release process: bloom only allows for one unique version at a time and it doesn't distinguish between bin and dev packages as well.
  2. Looks like Michael considered this already, because he wrote that "every binary has to be relinked with each new release of MoveIt!" This will break running setups on every release. While we research guys might not care about this, I'm curious what industry thinks about this? @mikeferguson? @mikepurvis?
  3. I think we should continue to try to avoid ABI breakage within ROS versions. Having this PR in place shouldn't be an excuse to relax this policy. Breaking ABI and API on a new ROS release is fine, I think - people are expecting changes in this case. However, I think this means that we cannot simply backport all fixes and features to older branches as proposed by @v4hn.
  4. To allow for releases without ABI changes (within a ROS version), the patch version should be not included / different from the soname patch version. I know that this will produce more effort on our side to take care of these changes. However, as said in 3. we should take care!
@mikepurvis

This comment has been minimized.

Copy link

commented Oct 17, 2016

Our deployment is via a bundled workspace now, so everything rebuilds each time— we don't worry about ABI at all. See: https://github.com/mikepurvis/ros-bundling

@davetcoleman

This comment has been minimized.

Copy link
Member

commented Oct 17, 2016

@rhaschke its not clear what you are proposing - just that we shouldn't include the patch version in the sonames?

After your points its also not clear to me what the advantage of this PR is - currently people who use MoveIt! debians sometimes have their catkin workspace broken after a ROS update because of ABI changes. With this new PR, it will be the same except that will always happen - correct?

@gavanderhoorn

This comment has been minimized.

Copy link
Member

commented Oct 18, 2016

The point is that with sonames, the breakage will be explicit (ie: things will not start because they cannot find the libraries they were linked against), while right now, things will appear to be fine (because all the libraries are there), but due to ABI incompatibilities, users may run into all sorts of hard to understand / debug segfaults.

As @rhaschke writes, with the current infrastructure (Bloom, etc) , the other advantage of sonames (ie: linking against a particular version, with several different versions all present in parallel) will not work.

@v4hn

This comment has been minimized.

Copy link
Member Author

commented Oct 18, 2016

On Mon, Oct 17, 2016 at 10:49:47AM -0700, Robert Haschke wrote:

  1. Usually, supporting sonames should include support for several installed lib versions in parallel. However, as far as I know, this is not possible with the ROS release process: bloom only allows for one unique version at a time and it doesn't distinguish between bin and dev packages as well.

Yes. Having sonames in the libraries supports having multiple versions of the same library installed. lib<libraryname>.so will point to one (e.g. the most current) version of lib<libraryname>.so.x.y.z but other (older) versions can still exist in lib<libraryname>.so.a.b.c. This ensures that newly compiled modules will link to the current version, while old modules are still linked to the old library version.

And also: Yes, bloom and OSRF's packaging schemes do not account for such version "transitions" (that's the term for it in Debian) at all. As far as I've been told this was discussed at length some years ago and (I've been told) the final argument was that OSRF does not want to "guarantee the stability this would imply". The argument does not make any sense to me, but this thread is clearly not the place to discuss this.
Anyway, anyone building the packages on their own (e.g. for Debian, Arch, or for their own personal use) is free to keep the old library versions around for transitions.

  1. Looks like Michael considered this already, because he wrote that "every binary has to be relinked with each new release of MoveIt!" This will break running setups on every release.

Yes, this is intentional.

While we research guys might not care about this, I'm curious what industry thinks about this? @mikeferguson? @mikepurvis?

All "industry" setups I know (including OSRF's build system) rebuilds the whole dependent software stack for each update.
This is precisely because most ROS components do not use sonames and break ABI whenever they think it makes sense.

  1. I think we should continue to try to avoid ABI breakage within ROS versions.
    Having this PR in place shouldn't be an excuse to relax this policy.

We should definitely minimize ABI changes, I agree. Also to avoid having to recompile your whole moveit development workspace all the time.
But the whole point of this request is to allow ABI breakage between releases within a single ROS distribution.
We receive requests such as an fcl Object cache and I don't think it is an option at the moment to merge these only to the most current branch.
Especially when this most current branch targets a different set of versions for the dependencies (e.g. kinetic-devel when the request targets indigo-devel).
Imho experience tells us, that full ABI stability within a ROS distribution for a research oriented library as MoveIt is a pretty illusive goal..

  1. To allow for releases without ABI changes (within a ROS version), the patch version should be not included / different from the soname patch version. I know that this will produce more effort on our side to take care of these changes. However, as said in 3. we should take care!

In theory I agree. This does not work with our current versioning scheme though.
If we would either change the library names to include the ROS distribution or increase the major version with each branch we could get around that, but I don't consider either of these a good idea.

Breaking ABI and API on a new ROS release is fine, I think - people are expecting changes in this case.
However, I think this means that we cannot simply backport all fixes and features to older branches as proposed by @v4hn.

Of course ABI and API are two entirely different things. We should definitely not backport any API change and did not do that in the recent past.
But having the full version as the soname allows to have new features that break ABI in "older" ROS distributions.
Because users provide patches for the branches they actually use, we often get patches for these branches that also break ABI for legitimate reasons (see for example the fcl request above).
It sounds just wrong to me to tell them their change will not be merged in the branch they want to merge it in.

  1. To allow for releases without ABI changes (within a ROS version), the patch version should be not included / different from the soname patch version.

I considered this and don't think this makes sense for the moment. It would leave us with the same problems we have right now.

@rhaschke

This comment has been minimized.

Copy link
Collaborator

commented Oct 18, 2016

I think, we agree on most points. My post was just to bring some pros and cons of the approach to our attention. Sorry, if I failed @davetcoleman.

  1. To allow for releases without ABI changes (within a ROS version), the patch version should be not included / different from the soname patch version. I know that this will produce more effort on our side to take care of these changes. However, as said in 3. we should take care!

In theory I agree. This does not work with our current versioning scheme though.
If we would either change the library names to include the ROS distribution or increase the major version with each branch we could get around that, but I don't consider either of these a good idea.

I agree. However, I see a third option: increasing the patch level of soname independent of the patch level of the release version (slower or leaving out / not increasing when ABI stability is maintained).

version  soname
0.8.3    0.8.3
0.8.4    0.8.3 (ABI stability was maintained)
0.8.5    0.8.5 (ABI broken)

Because users provide patches for the branches they actually use, we often get patches for these branches that also break ABI for legitimate reasons (see for example the fcl request above).
It sounds just wrong to me to tell them their change will not be merged in the branch they want to merge it in.

I didn't argued against backporting at all, but to carefully think about what to backport and what not. Furthermore, I would like to reduce the effort to rebuild downstream packages as much as possible - which is possible if we manually increase the patch version of SONAMES.

  1. To allow for releases without ABI changes (within a ROS version), the patch version should be not included / different from the soname patch version.

I considered this and don't think this makes sense for the moment. It would leave us with the same problems we have right now.

I think, if we increase the patch version manually, it could work. Maybe, you didn't yet considered this option.

@rhaschke

This comment has been minimized.

Copy link
Collaborator

commented Oct 18, 2016

On telephone, @v4hn and I agreed to use soname = patch version for this next release. However, in future we should try to bump the patch version only on ABI changes.

@davetcoleman

This comment has been minimized.

Copy link
Member

commented Oct 18, 2016

This PR still only covers moveit_core and is not ready to be merged in. This change should also be held off until the next Kinetic release - a line must be drawn in the sand for releasing software or it will never happen. There is still too much debate going on here.

@mikeferguson

This comment has been minimized.

Copy link
Member

commented Oct 18, 2016

How about a middle of the road that promotes getting a kinetic release out, but also managing the upgrade path:

  • We do an initial release of Kinetic based on the current state. In the announce email we make it very clear that SONAMEs are coming, and that our next release will include them (Effectively, the library name with no version is the first "version" of SONAMES). We also make it clear that we are making no ABI promises with the current Kinetic release.
  • SONAME support gets merged into Kinetic/Jade as soon as the PR is ready and fully reviewed.
  • We merge SONAME support for Indigo as soon as we identify the next ABI breakage (it's bound to happen). That way, we don't double-break our users (adding SONAMEs in a release that includes no other ABI breakage).
@v4hn

This comment has been minimized.

Copy link
Member Author

commented Oct 19, 2016

This PR still only covers moveit_core and is not ready to be merged in. This change should also be held off until the next Kinetic release

I just added the remaining libraries. I was too tired to do this yesterday evening.
I will test this further today and don't expect any problems.
In my opinion this can be merged today, because there is not much to review.
I simply added a PROPERTIES VERSION line for each add_library in the repo.
Also @rhaschke agreed that his objections can be discussed after we have this change in for the release.

We do an initial release of Kinetic based on the current state. In the announce email we make it very clear that SONAMEs are coming, and that our next release will include them (Effectively, the library name with no version is the first "version" of SONAMES). We also make it clear that we are making no ABI promises with the current Kinetic release.
SONAME support gets merged into Kinetic/Jade as soon as the PR is ready and fully reviewed.
We merge SONAME support for Indigo as soon as we identify the next ABI breakage (it's bound to happen). That way, we don't double-break our users (adding SONAMEs in a release that includes no other ABI breakage).

@mikeferguson Your whole proposal presupposes that binaries built against libxyz.so break when you add an soname to the next release of that library. This is not the case! The build still provides (and has to provide) a symlink libxyz.so pointing to the named library file.
This is exactly why I want to have sonames in this release! Because we can only mark ABI breakage in releases after we have sonames in already.

moveit_ros_planning
moveit_ros_visualization
)

This comment has been minimized.

Copy link
@v4hn

v4hn Oct 19, 2016

Author Member

This is the only non-trivial change I did: I had to move the catkin_package command above the library declarations.
This is required because the resp. add_library and set_target_properties commands should stay near each other, but ${${PROJECT_NAME}_VERSION} is defined by catkin_package.

@v4hn v4hn force-pushed the v4hn:pr-kinetic-sonamesl branch from fc32d76 to 8f3d19a Oct 19, 2016

v4hn added some commits Oct 9, 2016

add full VERSIONs / SONAMEs to all core libraries
As a result the libraries do not install as `libmoveit_xyz.so` anymore,
but as `libmoveit_xyz.so.${MOVEIT_VERSION}` and only provide `libmoveit_xyz.so`
as a symlink pointing to the versioned file.

Because this sets each library's SONAME to the *full version*, this enforces
that *every* binary links with the versioned library file from now on and
has to be relinked with *each* new release of MoveIt!.

The alternative would be to set the SONAME to `$MAJOR.$MINOR` and ignore the patch version,
but because we currently stay with one `$MAJOR.$MINOR` number within each ROS distribution,
we had (and likely will have) ABI changes in the `$PATCH` version releases too.

The reason for this commit is that it is practically impossible to maintain full ABI compatibility
within each ROS distribution and still add the the features/patches the community asks for.
This has resulted in more than one ABI-incompatible MoveIt! release in the recent past
within a ROS distribution. Because the libraries have not been versioned up to now,
there was no way to indicate the incompatible changes and users who did not rebuild
their whole workspace with the new release encountered weird and hard-to-track segfaults
or broken behavior.

@v4hn v4hn changed the title add full VERSIONs / SONAMEs to all core libraries add full VERSIONs / SONAMEs to our libraries Oct 19, 2016

@jspricke

This comment has been minimized.

Copy link
Contributor

commented Oct 19, 2016

+1 for the new commits as well. Looking really good :).

@rhaschke
Copy link
Collaborator

left a comment

+1. Did you ensured, that you don't miss a library?

@v4hn

This comment has been minimized.

Copy link
Member Author

commented Oct 19, 2016

Yes. I compiled the whole repository in an otherwise empty namespace and checked that all install libraries have an soname-version and a .so-symlink .

@davetcoleman

This comment has been minimized.

Copy link
Member

commented Oct 19, 2016

I also just tested this locally in a fresh workspace and verified all libraries are consistently setup with sonames.

As an aside, would we want to apply this same change to geometric_shapes?

@davetcoleman davetcoleman merged commit 0a7a895 into ros-planning:kinetic-devel Oct 19, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

130s added a commit to 130s/moveit-2 that referenced this pull request Oct 21, 2016

add full VERSIONs / SONAMEs to all libraries (ros-planning#273)
* add full VERSIONs / SONAMEs to all core libraries

As a result the libraries do not install as `libmoveit_xyz.so` anymore,
but as `libmoveit_xyz.so.${MOVEIT_VERSION}` and only provide `libmoveit_xyz.so`
as a symlink pointing to the versioned file.

Because this sets each library's SONAME to the *full version*, this enforces
that *every* binary links with the versioned library file from now on and
has to be relinked with *each* new release of MoveIt!.

The alternative would be to set the SONAME to `$MAJOR.$MINOR` and ignore the patch version,
but because we currently stay with one `$MAJOR.$MINOR` number within each ROS distribution,
we had (and likely will have) ABI changes in the `$PATCH` version releases too.

The reason for this commit is that it is practically impossible to maintain full ABI compatibility
within each ROS distribution and still add the the features/patches the community asks for.
This has resulted in more than one ABI-incompatible MoveIt! release in the recent past
within a ROS distribution. Because the libraries have not been versioned up to now,
there was no way to indicate the incompatible changes and users who did not rebuild
their whole workspace with the new release encountered weird and hard-to-track segfaults
or broken behavior.

* add SONAMES to all non-core libraries too

130s added a commit to 130s/moveit-2 that referenced this pull request Oct 21, 2016

add full VERSIONs / SONAMEs to all libraries (ros-planning#273)
* add full VERSIONs / SONAMEs to all core libraries

As a result the libraries do not install as `libmoveit_xyz.so` anymore,
but as `libmoveit_xyz.so.${MOVEIT_VERSION}` and only provide `libmoveit_xyz.so`
as a symlink pointing to the versioned file.

Because this sets each library's SONAME to the *full version*, this enforces
that *every* binary links with the versioned library file from now on and
has to be relinked with *each* new release of MoveIt!.

The alternative would be to set the SONAME to `$MAJOR.$MINOR` and ignore the patch version,
but because we currently stay with one `$MAJOR.$MINOR` number within each ROS distribution,
we had (and likely will have) ABI changes in the `$PATCH` version releases too.

The reason for this commit is that it is practically impossible to maintain full ABI compatibility
within each ROS distribution and still add the the features/patches the community asks for.
This has resulted in more than one ABI-incompatible MoveIt! release in the recent past
within a ROS distribution. Because the libraries have not been versioned up to now,
there was no way to indicate the incompatible changes and users who did not rebuild
their whole workspace with the new release encountered weird and hard-to-track segfaults
or broken behavior.

* add SONAMES to all non-core libraries too
@v4hn

This comment has been minimized.

Copy link
Member Author

commented Nov 11, 2016

On Wed, Oct 19, 2016 at 10:35:41AM -0700, Dave Coleman wrote:

would we want to apply this same change to geometric_shapes?

I don't think so. At least not the way we use sonames in MoveIt now.
MoveIt is changing rather rapidly, so full sonames within a distro make sense to allow breaking the ABI in releases within the distro.

For a package like geometric_shapes, I believe it shouldn't be a problem to keep the ABI stable within each ROS distribution,
so it's not that important to have sonames there. If we want to add them there, they should be bumped by hand.

v4hn added a commit to v4hn/moveit that referenced this pull request Dec 15, 2016

add full VERSIONs / SONAMEs to all libraries (ros-planning#273)
This is similar to ros-planning#273 / 0a7a895,
but hard-codes the version for each library instead of using the project's version.
Thus, we have to bump the version of a library *manually* if we break ABI in a release.

=== Below is the original commit message of the patch targeting the kinetic branch.

* add full VERSIONs / SONAMEs to all core libraries

As a result the libraries do not install as `libmoveit_xyz.so` anymore,
but as `libmoveit_xyz.so.${MOVEIT_VERSION}` and only provide `libmoveit_xyz.so`
as a symlink pointing to the versioned file.

Because this sets each library's SONAME to the *full version*, this enforces
that *every* binary links with the versioned library file from now on and
has to be relinked with *each* new release of MoveIt!.

The alternative would be to set the SONAME to `$MAJOR.$MINOR` and ignore the patch version,
but because we currently stay with one `$MAJOR.$MINOR` number within each ROS distribution,
we had (and likely will have) ABI changes in the `$PATCH` version releases too.

The reason for this commit is that it is practically impossible to maintain full ABI compatibility
within each ROS distribution and still add the the features/patches the community asks for.
This has resulted in more than one ABI-incompatible MoveIt! release in the recent past
within a ROS distribution. Because the libraries have not been versioned up to now,
there was no way to indicate the incompatible changes and users who did not rebuild
their whole workspace with the new release encountered weird and hard-to-track segfaults
or broken behavior.

* add SONAMES to all non-core libraries too

v4hn added a commit to v4hn/moveit that referenced this pull request Dec 15, 2016

add full VERSIONs / SONAMEs to all libraries (ros-planning#273)
This is similar to ros-planning#273 / 0a7a895,
but hard-codes the version for each library instead of using the project's version.
Thus, we have to bump the version of a library *manually* if we break ABI in a release.

=== Below is the original commit message of the patch targeting the kinetic branch.

* add full VERSIONs / SONAMEs to all core libraries

As a result the libraries do not install as `libmoveit_xyz.so` anymore,
but as `libmoveit_xyz.so.${MOVEIT_VERSION}` and only provide `libmoveit_xyz.so`
as a symlink pointing to the versioned file.

Because this sets each library's SONAME to the *full version*, this enforces
that *every* binary links with the versioned library file from now on and
has to be relinked with *each* new release of MoveIt!.

The alternative would be to set the SONAME to `$MAJOR.$MINOR` and ignore the patch version,
but because we currently stay with one `$MAJOR.$MINOR` number within each ROS distribution,
we had (and likely will have) ABI changes in the `$PATCH` version releases too.

The reason for this commit is that it is practically impossible to maintain full ABI compatibility
within each ROS distribution and still add the the features/patches the community asks for.
This has resulted in more than one ABI-incompatible MoveIt! release in the recent past
within a ROS distribution. Because the libraries have not been versioned up to now,
there was no way to indicate the incompatible changes and users who did not rebuild
their whole workspace with the new release encountered weird and hard-to-track segfaults
or broken behavior.

* add SONAMES to all non-core libraries too

cschindlbeck pushed a commit to cschindlbeck/moveit that referenced this pull request Aug 16, 2017

Merge pull request ros-planning#273 from hemes/indigo-devel
Added maximum acceleration scaling factor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.