Thufir <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 23 Sep 2006 09:30:36 +0100:
> [Off topic] Why fedora can't simply copy, and maybe improve, gentoo > e-builds, being, of course, an homage to the BSD port system, is a > mystery to me. Pride? FWIW... I'm a Gentooer myself, so I obviously think it's the best solution for me. =8^) However, I recognize that compiling from source isn't everybody's idea of fun, or what they want to spend their time on, and indeed, that for users with a single core/cpu of less than say 2 GHz, it'd be a rather huge burden, both for the time compiling and the fact that a single core simply can't multitask as efficiently as two or more, so for such a user there WILL be a major tradeoff in terms of time spent keeping the system updated. The problem is, and I didn't really understand the full implications of this until I had spent some time on Gentoo and could actually /see/ them, once one decides to go with a primarily binary (that is, upstream compiled) solution, HUGE compromises must be made in terms of dependency flexibility vs. supported options. Where compile time choices must be made in what one supports and therefore what one depends on, no matter WHICH way one goes, there are serious tradeoffs. Either one supports all sorts of stuff but ends up bringing in all sorts of bloat for those that don't use it all -- and few actually use it /all/, the problem is the part that gets used depends on the deployment, or one seriously limits support for optional features by choosing not to depend on them and thereby not to have that bloat. There's no single right answer, nor /can/ there be. Gentoo's answer is to leave the compiling to the end user/sysadmin, who can then choose his own balance on the continuum between lean but spartan and supporting everything but hugely bloated. However, that has its own tradeoffs, namely all the time spent compiling by all those end users, vs centralizing the compiling (and the dependency/support choices). That's why you don't normally see a binary distribution choose to support KDE and GNOME equally. They standardize on one or the other, building in full support for it, and for the other, omit some of the advanced support and the dependencies it would require. Even that is incredibly bloated however, for end users who choose say xfce, and even worse for those running servers or whatever who don't want X installed at all. It's simply impossible to be all things to all people, so the distributions specialize. That's a /good/ thing, and remains a /good/ thing whether you agree with the specialization of an individual distribution or not, because there are bound to be other choices out there better matching your specific needs! =8^) So... we have Fedora, which as with many distributions, has chosen to target the primarily binary installing end user. It's certainly a legitimate choice, but as with any alternative at that level, it comes with its own set of costs as well as benefits. The biggest of these costs is that by definition of being a binary distribution, it limits itself to a particular feature set and emphasis in terms of what it chooses to support. However, Fedora being quite popular, it has developed an entire ecosystem of alternative repositories, each emphasizing its own angle, if you don't happen to like the particular angle Fedora main and extra has chosen to implement. By definition, some of these repositories will be incompatible with others, due to their differing emphasis leading to different compile-time choices and therefore differing dependencies. That's just the way things are -- there's no way around it except by going the Gentoo route and leaving all those choices along with the job of doing all that compiling, to the end user sysadmin, and that choice as well has serious negatives. Fedora /could/ copy and possibly improve on Gentoo and the BSD ports system. However, that would either be an exercise in futility, if they tried to retain their primary prebuilt binary focus, or would be a /dramatic/ change from what RH/Fedora had done traditionally, with a switch to a source based, compiled at the end user end, focus. I don't believe most Fedora users would want the latter, or they'd already be Gentoo users, not Fedora users, right now. Indeed off topic, but perhaps it'll enable a better understanding of the dynamics of this particular part of the FLOSS ecosystem, for more than just one person on the list. > on topic: if I upgrade, or run two versions of pan, it won't make a > difference because pan is just connecting to leafnode, yes? > > Things like, which messages are read, or not, or which groups are marked > "subscribed", can that info carry over to the updated version of pan? > The messages themselves are in leafnode, of course (as is the > "interesting.groups" directory, which is related to the subscribed > groups in pan). It depends on the versions you have in mind. Old-pan, 0.14.x, and new-pan, >=0.90, use entirely different directories by default, which is a good thing since their configuration files are quite different. Thus, you can run them in parallel with no interference, but no, they won't be picking up each other's settings, including each other's tracking of read messages (except if you directly enable that, see below). With two versions of new-pan, >=0.90, it's possible to run separate directories as well, if desired, setting the $PAN_HOME variable separately for each, but I'm not sure why one would /want/ to run two different new-pan versions. Either the latest works and one will want to run it, or it doesn't for some reason, and one wants to stick with a slightly older version until the problem is resolved. (OTOH, the separate dirs ability comes in handy for running separate instances of the same pan version, say one for binaries and one for text, if desired. That's one way of working around pan's inability to categorize and group newsgroups. It also allows one to have different binary group settings, say a larger cache and different expiration, than for text groups.) As for the differences between old-pan and new-pan configurations, similar and partially compatible formats are used in some cases, but not all. In particular, the score file and newsrcs are similar. For the score file, new-pan is stricter in the slrn format than old-pan was, as old-pan allowed the xnews variant format while new-pan doesn't so much. Specifically, slrn (and new-pan) treat newsgroup matching in the score file as * wildcard type, while xnews treated them as regular expressions. Old-pan tried to figure out which was being used and match accordingly, a strategy that's certainly going to be complex and fraught with the possibility of misinterpretation. The one xnews thing that new-pan retains is case insensitivity, where slrn's score format is case sensitive both in the regex matches and the newsgroup/*-wildcard matches, xnews and pan (both old and new) are case insensitive by default. Thus, if you used regex newsgroup matching in your old-pan scorefile (as I did), you'll have to redo it for new-pan. That isn't all bad, however, as I took the opportunity to reorganize and drastically simplify my scorefile. It now has only six scores in two sections, according to the pan event log, altho both the scores and the sections are compound -- multiple individual matching tests per entry. Scorefile documentation resources (see the xnews one for how to make the regex matching case sensitive if desired, otherwise, pay more attention to the slrn one): slrn: http://www.slrn.org/docs/score.txt xnews: http://xnews.remarqs.net/scoring.txt The newsrc file format is I believe unchanged, but new-pan uses different filenames. Symlinking (or simply copying/moving it over if you are switching, not intending to run both) should work, however, tho I'd ensure I had backups during initial testing in case the newsrc for one server gets accidentally used for a different one, and therefore screwed up. I /think/ the cache is the same format, but I'm not sure on that and didn't try using the same cache here, so can't verify it. The accels.txt is a similar format, but of course with different entries, so don't try to share it between old and new pan. Most other files are different. Certainly the tasks list is different, as the new format is simply an nzb file. The preferences file like accels.txt is a similar format (xml based) but with enough different settings I'd not try to copy it over. -- 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 _______________________________________________ Pan-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/pan-users
