Tom Mueller wrote:
> Shawn Walker wrote:
>>> feed.py:
>>> I don't see a method for customizing the values for feed_authority and
>>> feed_author_*.  This is essential for repositories that are not 
>>> serving up
>>> OpenSolaris content.
>>>     
>>
>> I agree, but that sort of falls under bug 2239.
>>
>> I could add that to this wad, though I'm not certain yet how I'll 
>> implement it.
>>   
> How about "pkg.depotd set-property" and so forth.  I know where you can 
> get some set-property code :-)
> It might not be acceptable to have a single program that can act either 
> as a daemon or a command.
> 
> I agree that there is overlap here with 2239.

I'll look into it. I'm trying to avoid feeping creaturitis :-)

>>> feed.py, various lines that use cherrypy.url():
>>> What happens when the pkg.depotd server is behind a front-end reverse 
>>> proxy
>>> web server?  Will the web server rewrite the Atom feed to replace the
>>> absolute URLs generated by cherrypy.url()?
>>>     
>>
>> I don't believe it will rewrite the URLs.
>>
>> As I understand it, I need a full, absolute URL to the feed:
>> http://tools.ietf.org/html/rfc4287#section-4.2.6
>>
>> Uncertain what to do with this.
>>   
> I'm not sure either.  I thought the Host header came into play here, but 
> that doesn't solve everything.  This might have to be done with 
> rewriting rules in the proxy.

I believe there was a blurb on the cherrypy website about this 
particular situation since reverse proxy is the most common setup for 
cherrypy usage. I'll look into this more.

  >>> feed.py, line 125:
>>> Would it be worth it to try to distinguish between a new package 
>>> being added
>>> to the catalog vs. an update to a package that was already in the 
>>> catalog?
>>>     
>>
>> Unfortunately, modules/updatelog.py only provides history for adding 
>> packages.
>>   
> I was thinking that when feed.py is processing an "add", it would look 
> for and earlier version of the package in the catalog, and if there is 
> one, then treat the add as an update.  The information for an update 
> could also include the change log, etc.

Honestly, that's more complex than I was wanting to be. I wouldn't be 
comfortable with the feed code being so directly tied to the catalog -- 
it's already tied at the hip to the updatelog.

With that said, I would be comfortable with extending the catalog API to 
be a bit more expressive to make this possible.

Would "not this wad" for now be acceptable?

-- 
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to