[Pan-users] Re: Keeping settings when upgrading from 0.14.2.91 (Fedora Core 5) to 0.123 (Fedora Core 6)

[Duncan]

Don Waugaman <address@hidden> posted
address@hidden, excerpted below, on  Tue, 06 Mar 2007
00:55:21 -0700:

> I recently upgraded a system from Fedora Core 5 to 6 and was rather
> surprised to see pan start up as if it were a brand new installation,
> needing me to restore all of my settings.  A little investigation showed
> that the old Fedora Core 5 pan (0.14.2.91) had been superseded by a
> newer C++-based version (0.123), which created a new directory (.pan2)
> for its configuration files.
> 
> I'd really like to convert my old files under .pan automagically if
> there's a way - 'twould be rather a pain to do it all by hand.  Can this
> be done, and what's the magic incantation to do it?  Or should I go
> ahead and start keying in my server settings again?

Welcome! =8^)

In regard to new-pan vs. old-pan and upgrading, there's good and bad 
news.  The short version is that new-pan is a complete rewrite in (as you 
mentioned) C++, and that as part of that rewrite, the way the config was 
stored changed enough to make switching directories (to ~/.pan2 by 
default) a very wise idea.  Never-the-less, certain aspects of the 
configuration are similar enough to port over.

The longer version... well, could be pretty long, as you can see if you 
look in the list archives at my responses in the past. <g>  So, here I'll 
try for an intermediate length version, and you can check the archives or 
ask as you have additional questions.

First thing upgraders should be aware of is that certain aspects of the 
PAN GUI have changed in ordered to better support some of the newer 
features.  It **WILL** take a bit of getting used to, and advanced users 
will find a couple things from the old version still missing in the new 
version.  If you wish, you can probably continue to run the old version 
for some time, even alongside the new version if desired (basically, 
rename the binary of the one, I named my old one pan.14, then install/
reinstall the new one, they use different config dirs as you know, so 
this is possible).  However, the old C version is effectively dead code 
now, and no further upgrades will be made available, so it'll gradually 
get more and more crufty and harder to keep running on your system as 
everything else moves beyond it.  Therefore, regardless of whether you 
keep old-pan short-term, you should plan on eventually switching to the 
newer version, or if it doesn't suit you for some reason, look for other 
alternatives (or ask here if it's something that can be changed).

The two BIGGEST changes in new-pan, from a user perspective, is (1) that 
it's MUCH more scalable now, and (2), that it's a true multi-server 
client now, not just a single-server client (in interface terms) that 
happens to let you configure several servers, but then you basically work 
with them separately, as in the old version.  Both of these changes had 
far reaching effects on the configuration at the back end, while the 
multi-server view on the front-end had serious implications for the UI 
and the configuration UI.  That said, you'll recognize the same "style" 
in many of the details, and many of the same design philosophies and 
goals apply, including both 100% GNKSA compliance and that pan ultimately 
be a "Pimp-Ass Newsreader!" (aka PAN, tho for political correctness 
reasons the acronym is seldom expanded any longer, and the lower-case 
form has become predominant).  You'll notice both of those right away as 
you work with the new pan, and it helps to keep them in mind as you 
explore new pan and the way it has changed, as the reasons for the detail 
changes often become apparent if you do.

pan's better scaling, in particular, helps on large groups with more than 
a few hundred thousand posts -- pan now starts to noticeably drag at say 
a couple million posts, instead of the couple hundred thousand before, 
and can handle over 5 million as compared to the say half a million 
before, before things become /unbearable/.  (It's likely more like 10 
million now, as the 5 million figure was before some additional memory 
tweaking and memory leak fixing took place.)  If you like to keep around 
quite a few headers and a large cache, you'll also notice that pan's 
start time is better than it was.  Where it used to take over a minute 
here (from cold memory cache), it now loads several times the data in 
only about 20 seconds.  For those with less data, where there used to be 
a noticeable delay (say 20 seconds), it's now much closer to normal/
instant.  I used to keep pan loaded most of the time, simply to avoid the 
reload time, but now I don't have to.  =8^)

Single server users won't notice that change as much, but particularly 
binary group users that used to pull from several servers to get 
completion should find the new pan UI VASTLY easier to work with, once 
they get used to it, anyway.

As I said, however, all that comes at a cost of a not fully compatible 
config.  Still, some things can be reused, making the switch easier.  In 
particular:

* The score file is nominally the same, tho it's a bit stricter to slrn 
rules now, not taking the xnews variations it did before.  Specifically, 
the xnews regex newsgroup entries will need edited by hand to follow the 
* wildcard newsgroup entry spec (doc URL below).  I had been using regex 
news entries here, so had to edit my score file to make it work on new-
pan.  However, after reading the documentation and getting a better 
picture of the file format, I took the opportunity to reorganize my 
scorefile at the same time, and instead of hundreds of individual rules 
as I had before, I now have, according to pan, "6 scoring rules in 2 
sections", MUCH more efficient, and easier to manage for me as well. =8^)

SLRN scorefile doc (pan remains case insensitive, as that's normally 
what's wanted anyway, and I don't believe it implements the advanced 
stuff like includes or scores on anything but overview headers, yet):
http://www.slrn.org/docs/score.txt

* While old-pan could export standard *.newsrc format files, new-pan uses 
them by default.  It's therefore possible to start old-pan (if you still 
have it around or reinstall it, and assuming you didn't have it setup to 
export newsrc files automatically), export each server into its own 
newsrc file, then use those with new-pan.  The easiest way to actually 
import them would be to setup each new server but DON'T download the 
newsgroups list for it, quit new-pan, then overwrite the blank new 
newsrc-* files with the appropriate newsrc files exported from old-pan.  
New-pan should then use the "imported" files next time it starts.

* The cached posts themselves are I think compatible, as simply a direct 
dump of what came down the wire.  I didn't actually test this, however, 
as I simply used old-pan and new-pan side by side for awhile, and still 
have old-pan installed to answer questions against when needed, tho I've 
not actually downloaded anything with it for months.

Everything else is I believe new configuration, tho some of it is sort of 
similarly organized compared to the old configuration files.  Setting 
names and the like have changed, as well as file names, however, and it's 
simply easier to reconfigure the settings than it is to try to match them 
up manually.

One other point of significance to mention.  New-pan has a number of 
settings that were considered too advanced for pan's GUI config, which 
Charles wants to keep simple and intuitive, but which never-the-less are 
exposed for power users willing to edit their config manually.  For 
instance, while GNKSA requires that no more than four connections be 
configurable to a server to avoid DoSing it, a common request has been 
for additional connections, since some servers specifically allow them 
(my pay server allows up to eight).  The new-pan compromise is that the 
GUI lets you configure up to four connections, but in the servers.xml 
config file itself, it's a simple integer setting that one can set as 
desired.  

Likewise, pan's config GUI has no way to set cache size, with a default 
of I believe 10 MB, suitable for some text and those that prefer to save 
binaries directly, but not for those (like me) that prefer to download 
binaries to cache and work from there, and/or to keep text group messages 
around after they expire on the server (which is now possible).  There's 
a cache size setting in preferences.xml, however, which pan honors if you 
change it, and which I use here set to 5 gig for my text group pan 
instance, and 12 gig (on a dedicated partition) for my binary group pan 
instance.

What's that, I can imagine you saying, pan does separate instances now?  
Yes, and it actually comes in quite handy, since it's just one long list 
of subscribed groups now, no way to separate it by setting up a separate 
"server" just to group subscribed groups, as used to be possible.  pan 
looks in the environmental variable $PAN_HOME, if set, to see where its 
config is stored.  Thus, you don't have to use ~/.pan2 unless you want 
to, and change it by setting and exporting this variable before starting 
pan.  I've taken advantage of this to setup three separate configs, text 
for my text groups, bin for my binary groups, and test for just looking 
around and visiting groups I may not want to subscribe to long term.  
Where the settings are the same (as for the scorefile and accels.txt), I 
simply symlink to a global config dir that has only the common config 
files in it.  I then use little shell scripts (pan.tst, pan.bin, etc) to 
set the appropriate variables and do a couple other things before 
starting the pan binary, and have my X menu (kmenu, in my case) entries 
launch the appropriate shell script instead of the pan binary itself.  
Thus, as mentioned above, the preferences.xml for my text instance has a 
different cache setting than the preferences.xml for my binary instance, 
because they are separate configs located in separate dirs.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman