Potential Issues with Plugins using Packages for emhttp files


dlandon

Recommended Posts

If you are using packages to install the emhttp files you could be creating a problem if the packages are versioned.  If a plugin is installed it will install a versioned package.  An update to the plugin would create a second package with a new version that may not be cleaned up when the plugin is removed.  I see this behavior in some plugins.

 

For example:

Plugin installed and initial package is installed:

my-plugin.2015.09.02

 

Then the package is updated:

my-plugin.2015.10.12

 

Now both packages are installed.

 

If the plugin is removed and the second package is removed and the first left in place, the removal of the emhttp files will fail because the first package is holding them.  The emhttp files left behind can be troublesome and confusing because the plugin was supposed to be removed.

 

I don't know if it is better to always install the package as my-plugin and upgrade it in place, or remove the older version first.  I don't do my plugins this way so I can't offer a good solution.

 

The reason I mention this is that it could create support issues for users that do updates and then remove a plugin.  Of course a reboot will clean all this up, but the idea is to not have to do a reboot.

Link to comment

I've always seen that behaviour with CA, where upon removal it almost always says "file found in another package... skipping".  Never really understood where that came from, but now its making sense.  I always included at the end of the removal section, a force delete of all the files in the plugin directory anyways.

Link to comment

You now have a package with the files removed manually.  Don't know if this creates any issues or not, but is a bit messy.

 

Would it not be cleaner to remove the older packages or do an updatepkg to the original package instead of an updatepkg that creates a new package with a different name (version on the name)?

 

I use a tar to install the emhttp files in my plugins so I don't have to deal with these package issues.  I don't know if either method is better.

Link to comment

Until dmacias let me know the other day the reasoning for why it said "skipping files", I never really thought about it.

 

Any adverse affects?  Doubt it, as all of the emhttp files are removed via the rm -rf.  Proper Way of doing things?  Probably not, but I seriously doubt that I'm alone in the method that I was doing things. 

Link to comment

The plugin manager uses the slackware utility upgradepkg to install or upgrade packages.

 

The upgrade process that upgradepkg follows is to uninstall the old package first and then install the new package. This works fine if old and new package have the exact same name, but usually packages have a version or date number in their name, which makes old and new names different. For those circumstances it is required to include both names when calling upgradepkg. Like:

 

upgradepkg oldpackage%newpackage.tgz

 

This is a bit of a hassle, since sometimes it is unclear what old version you are upgrading from, I guess it is doable, but I decided to change all the Dynamix plugins to use a 'fixed' package name which makes the upgrade (or uninstall) rather straightforward.

 

Within the PLG file I verify the MD5 checksum of the package to see whether a package needs to be upgraded. This prevents unnecessary downloading of packages upon system reboot.

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.