[Mailman-Developers] Newlist/rmlist update

[Marc MERLIN]

On Tue, Jan 01, 2002 at 03:26:11PM -0500, Barry A. Warsaw wrote:
> 
> >>>>> "MM" == Marc MERLIN <marc_news@vasoftware.com> writes:
> 
>     MM> As promised, here's a patch that:
>     MM> 1) Adds the SPLIT_DIRS option which does this:
> 
> Some questions: what if you already have an `m' list or a `t' list?  I

I thought  about list  names of  less than 3  characters to  see if  the dir
hashing would work, but I forgot about this case.
So basically,  it means that  it'll get  a bit ugly  if you have  one letter
listnames.
For that  matter, it should work,  but your 't' list  would have directories
with other lists inside of it, not very pretty.

In other words we need at least a disclaimer in Default.py that if you turn
the option on, you'd better have at least 2 letters for all your lists.

> guess you can't mix and match split dirs installations with non-split
> dirs installations.  It also means...

You should be able  to, I wrote the patch with this in  mind. All it does is
move the creation place of new lists and sets a symlink back to the expected
place.
Unless I missed something (I've not  given this real life testing outside of
my laptop yet), I don't see why  it can't cohabit with lists created the old
way. Sure, it'd be inconsistent, but it should work.
Note too that rmlist was changed to  deal with both kind of lists (actually,
it just deletes all possible names)

>     MM> If everyone is cool with this, I'll write a tool to convert an
>     MM> existing installation to the new (optional) directory layout
>     MM> (I need this for lists.sourceforge.net)
> 
> ...that this tool will be essential.  Also, will the conversion script
> be able to go back to non-SPLIT_DIRS configuration?  This also hints

I hadn't  planned to write that,  but I don't expect  people casually switch
back and  forth. Besides, if  they hit 16K,  they won't be  able to  go back
anyway.  That said, it  shouldn't be too hard to write  something to go back
if someone  needs it. It's also  not too hard  to do it  by hand with  a few
shell commands, like
cd ~mailman/lists; /bin/rm *; mv */*/* .; /bin/rm -rf [a-z]
(untested and crude, but you get the idea)

> that maybe we don't need the SPLIT_DIRS variable, but perhaps we can
> simply auto-detect it (although if it makes life easier, I'm not
> opposed to the variable).
 
Mmmh, I'd rather not have mailman try  to be too fancy and try to autodetect
the setup,  besides, for someone  who can't  afford downtime (you'd  have to
stop mailman  while the convertion happens),  you could turn the  switch on,
and have new lists created the new way  while the old ones stay the way they
were.
The code was written  so that if you wanted to, you can  turn the setting on
and off for every other list.
 
> Are you sure other bits that look for the list's directory still work
> (like template searching, or extend.py)?  They should because of the
> symlinks.
 
I've  done basic  testing, but  nothing real  or life. That  said, the  idea
behind symlinks is that I wouldn't have  to care were all the code was since
indeed, it should follow the said symlinks.
 
> Also...
> 
>     MM> 2) Creates the pipermail html dir at list creation time so
>     MM> that you don't get an http error when you view the archive of
>     MM> a list that doesn't have messages yet
> 
>     MM> 3) rmlist now does what it advertises with -a (you couldn't
>     MM> erase archives after erasing a list)
> 
> These are both useful patches on their own, so it's best in general to
> split them up into individual patches.  I think I can strip them out
> from your diff, so don't worry about it this time.  I'll go ahead and
> apply these parts now, and if necessary you can re-generate the
> SPLIT_DIRS patch based on the above comments.

Yes, I  know about  splitting patches, I  usually do, but  as you'll  see in
splitting,  I'd  have had  to  write  two  versions because  the  SPLIT_DIRS
functionality modifies how 2 and 3 would have been written (a bit)

Marc
-- 
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
  
Home page: http://marc.merlins.org/   |   Finger marc_f@merlins.org for PGP key