[csw-maintainers] Preliminary package reviews

Dagobert Michelsen dam at opencsw.org
Mon Aug 16 18:45:44 CEST 2010


Hi Maciej,

Am 16.08.2010 um 13:07 schrieb Maciej (Matchek) Blizinski:
> No dia 16 de Agosto de 2010 10:39, Dagobert Michelsen
> <dam at opencsw.org> escreveu:
>> Hi Maciej,
>>
>> Am 16.08.2010 um 10:47 schrieb Dagobert Michelsen:
>>>
>>> - it would be nice if the repository link from the pkginfo
>>>   OPENCSW_REPOSITORY:
>>> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.1.x@10727
>>>  would be a link also to directly jump to the GAR manifest
>>
>> This
>>  https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.1.x@10727
>> would be need to be rewritten for browsing as
>>  http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/mysql5/branches/mysql-5.1.x?rev=10727
>
> Link to the repo:
> I find that talking directly to the subversion repository
> (gar.svn.sourceforge.net) is faster, for now I've linked to it.

I have two issues with this:
1. The link to the repository is not fixated to the revision, so if  
the file
in the repository received commits after the packaging you browse the  
current
version and not the one the package was built from.
2. The Trac repository browser allows immediate history browsing and  
is nicely
formatted
So if you want to keep the direct link to the repository I would like  
to have
an additional link ("Tracbrowser"?) with the rewritten URL to give the  
user
the choice which one to use.

> Readability of lists:
> I've addressed Peter's suggestion to expand the runpath and needed  
> soname lists.

Cool

> Table view:
> I like Dago's idea to create a table with sonames and runpaths, but
> haven't implemented it yet.

Thanks!

> Mechanism of submission:
> For now, there's only the tool to generate the HTML code.  I'm open to
> suggestions what the submission mechanism could look like.  (A
> command-line tool?  Something similar to submitpkg?)

I would like to fully integrate this in the mechanism we have right now:
- packages in experimental/ are directly made browsable by adding links
after each package. All packages in each subdirectory of experimental/
are checked together. If you don't want that just make additional
directories in experimental.
- packages in current/ and stable/ are checked in full and are directly
browsable from the package view on the website.

> Keeping the unpacked files:
> Currently, the extracted package is deleted as soon as statistics are
> collected.  I understand that you would like to open the files
> directly in the browser.  I wouldn't like to keep the unpacked files
> around.

Ok, what about if I already have an upacked version around and
give an extra parameter to pkgdb like
   -d /home/pkgbrowser/pkgs/078cf1b32e084b140d17ae2e054f07d0
that it automatically adds links to the unpacked files in
the given directory. There would also need to be a way to
specify the URL prefix under which this directory is reachable.


The directory would then look something like this:

pkgbrowser
|-- html
|   `-- 078cf1b32e084b140d17ae2e054f07d0.html
`-- pkgs
     `-- 078cf1b32e084b140d17ae2e054f07d0
         `-- CSWmemcached
             |-- install
             |   |-- copyright
             |   `-- depend
             |-- pkginfo
             |-- pkgmap
             `-- root
                 `-- opt
                     `-- csw
                         |-- bin
                         |   |-- amd64
                         |   |   `-- memcached
                         |   `-- memcached
                         |-- include
                         |   `-- memcached
                         |       `-- protocol_binary.h
                         `-- share
                             |-- doc
                             |   `-- memcached
                             |       `-- license
                             `-- man
                                 `-- man1
                                     `-- memcached.1



Best regards

   -- Dago



More information about the maintainers mailing list