Item8023: Debian installer is not up to date, and not maintainable by hand.

The Debian package is, in theory, updated every day from SVN, but this is not working.

For instance, http://foswiki.org/Extensions/WysiwygPlugin shows:

Plugin Version:      1150 (03 Dec 2008)
Change History:     
03 Dec 2008    Foswikitask:Item6041: fixed empty bullet list problem
22 Oct 2008    Fixed TWikibug:Item5961 (emphasis), TWikibug:Item6089 (backslash in verbatim) 
7 Aug 2008      Fixed TWikibug:Item5707 (mod_perl) 

But as of 3 Dec, my install shows:

Plugin Version:      17359 (11 Aug 2008)
Change History:     
7 Aug 2008    Fixed TWikibug:Item5707 (mod_perl) 

And trying to do a Debian update does not show an update available for WysiwygPlugin:

# apt-get -s upgrade | grep twiki
  twiki-directedgraphplugin tzdata
Inst twiki-directedgraphplugin [080119-1053] (080119-1060 fosiki.com:distributedinformation.com)
Conf twiki-directedgraphplugin (080119-1060 fosiki.com:distributedinformation.com)

So: 1) the repository is out of date and 2) the DebianPackage not allowing the user to install twiki extensions through configure

The result is an install that is unmaintained by the package and unmaintainable by the system administrator.

As my client occasionally gets corrupted text in his topic I wanted to update WysiwygPlugin. I am now going to have to install by hand and conclude that the DebianPackage is not ready for primetime.

---

Just in time for Sopan to upload the wrong thing to TWiki.org's Plugin web, I fixed the build script to grab things from t.o again. the debian packages aren't going to be any better than what is upstream. Yes, configure installations are a very bad idea if you're wanting to use a package management system, and proper web security.

closing with the assumption that you wanted the packages to mirror t.o.

-- SvenDowideit - 12 Dec 2008

---

Apologies if I should have started a new task, but this one seems to be very close to my issue!

I have today upgraded foswiki 1.0.0-1 to 1.0.4, using the fosiki.com repository. It worked very nicely.

However, I don't think I have the most up to date versions of the plugins that are included in the foswiki package.

Some plugins, such as WysiwygPlugin seem to be on a different version (svn revision and date), but are actually the same (last change 20081203). Others however, such as TinyMCEPlugin are different (I think). Installed version 1628 (08 Jan 2009), last change 20081206; compared to foswiki website version 3236 (2009-03-21), last change 20090121.

I did try to install the apparently out of date plugins from the debian repository, but they wouldn't install as doing so would overwrite the versions supplied by foswiki.

How can I keep these extensions up to date?

Thanks

-- EdMcDonagh - 07 Apr 2009

yes, extensions that are actually a part of the release are a big problem - that will involve re-writing the foswiki core package into several components. It won't happen soon, but I m working towards it.

-- SvenDowideit - 26 Apr 2009

I just had a terrible idea. Perhaps those extensions which overwrite files in core could be packaged into a different path or with an arbitrary extension... then the postinst script could mv or cp over the top of the core files

Just a thought...

-- PaulHarvey - 28 Aug 2009

yes, that is a terrible thought. what you're proposing (and people do doit) is to circumvent the packaging system making it unable to do its job - its pretty much more productive for is to fix the issue at its root.

-- SvenDowideit - 04 Oct 2009

Actually, if it can be canonically determined that an extension package should always override the base package irrespective of version, this can be handled fairly cleanly from inside the packaging system using dpkg-divert. You can then make the base package conflict with an extension package below a certain version to force that package to be uninstalled if the base package starts shipping a more recent version internally. That may not be a bad stopgap measure to take while things get properly separated out.

-- ZedPobre - 22 Oct 2009

dpkg-divert can only be used once though, and is usually used when an unrelated third party wants to modify the behavior of an existing suite. If you just want to replace the whole thing, it's a lot cleaner to just install a different package that Provides and Conflicts with the first (meeting basic dependencies and forcing the other package off the system). Since all Foswiki core and extension packages come from the same repository, it should be possible to be more cooperative than a diversion.

The problem is the same extension can be both in core (as a single monolithic package with core's version number) and as a completely independent package from trunk with its own unrelated version number. Having the same package name with two completely unrelated streams of version numbers would be confusing and probably bad.

A way to resolve it would be to first split the foswiki .deb into ~30 separate packages (eg. foswiki-core-empty-plugin, ...), and also make a foswiki-empty-plugin on trunk. Both could Provide and Replace foswiki-empty-plugin, only one could be installed at once, and foswiki-core could depend on either by depending on an unversioned foswiki-empty-plugin. It's more packages, but once you're at 200+ you might as well finish the job and make every installation choice a separate package, so it can all be rolled back or upgraded as the admin sees fit.

I believe separating the core package by extension has been discussed, but don't know if there was a concensus on it. I'm inclined to do it that way, but it's likely to be confusing and break a lot of stuff, so trunk-only.

There is also a cute Debian trick where the binary package version is different from the source package version - that might be another way to address the different version numbers and conflicts - two versions of the same package name can't be installed simultaneously, and it would be more apparent which was the latest.

-- DrakeDiedrich - 24 Oct 2009