Le 15/06/2010 18:29, Christopher Browne a écrit :
> Guillaume Lelarge <guillaume at lelarge.info> writes:
>>   * pubDate is hard to get in the good format. As a matter of fact, I
>>     have no idea how to get it on the right format.
> 
> How about...
> 
> PUBDATE=$(tar tfvj ${TARFILE} | head -1 | cut -d " " -f 4-5)
> ?
> 
> And how about
> AUTHOR=$(tar tfvj ${TARFILE} | head -1 | cut -d " " -f 2 | cut -d "/" -f 1)
> ?
> 
> Those mayn't be totally optimal, but they're surely better than
> nothing.
> 

Sure. PUBDATE has a specific format, and this is not the good one.
People could start complaining about it once it is published.

> I'd suggest looking at the names for "rc", and having a little bit of
> logic that assortedly reports:
> 
>  - "This is a release" if it doesn't say "rc"
>  - "This is a mere release candidate" if it does.
> 
> I think it's a fine idea for an RSS feed to include release
> candidates, particularly if it expressly tells the reader that that's
> what they are!
> 

You mean, having for example the 1.2.21, the 2.0.3, the 2.0.4-rc in the
versions.rss. Or only the 1.2.21 and the 2.0.4-rc. I can work with the
former. The latter has absolutely no interest to me.

> It's all pretty dependent on the combination of:
>   a) The format of output from tar.  But that shouldn't be *too* fragile, as 
>      a LOT of people depend on its behaviour, including how it outputs things.
> 
>   b) The naming conventions for releases.
> 
>      But again, that's not *too* fragile - I get hatemail (not too
>      hateful :-)) any time the names of tarballs vary from
>      expectations.
> 
>      Apparently folks with package management systems (e.g. - like
>      Debian dpkg, RPM, Ports) have some dependencies on how things are
>      spelled.
> 
> I'm fine with the direction you seem to be going on this; if you like
> my suggestions, feel free to add them in.
> 

I added them. So new file attached. The other files don't change.

> And I expect that the right answer for compiling the whole RSS is for
> each Makefile to have a rule that essentially says:
> 
>    "rummage around in the nearby download directories and generate a
>    new central RSS file based on the combination of all of the files."
> 
> It's "expensive" in one sense, since each time you run "make" in one
> of the download directories, it regenerates the main rss file.  But
> since that's just constructed by cat'ing a few files together, it's
> not *REALLY* expensive.
> 
> We already need to run "make" in one of the download directories
> whenever we deploy a new download, to generate checksums.  Getting
> that to regenerate RSS at no visible cost is an eminently reasonable
> price to pay.

Thanks.


-- 
Guillaume
 http://www.postgresql.fr
 http://dalibo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rss.sh
Type: application/x-sh
Size: 1050 bytes
Desc: not available
Url : http://lists.slony.info/pipermail/slony1-general/attachments/20100617/f6e47048/attachment.sh