[csw-maintainers] http://www.opencsw.org/packages/<pkg>: Add GAR build recipe URL to package page?

[Dagobert Michelsen]

Hi Phil,

Am 17.11.2010 um 18:49 schrieb Philip Brown:
> On 11/17/10, Dagobert Michelsen <dam at opencsw.org> wrote:
>> Hi,
>>
>> Am 17.11.2010 um 16:06 schrieb Ben Walton:
>>> Excerpts from Philip Brown's message of Tue Nov 16 13:19:04 -0500
>>> 2010:
>>>> csw/mgar/pkg/apache2/trunk at 11200
>>>>
>>>> "csw/mgar/pkg" is also pretty much redundant. Shouldnt we strip  
>>>> that
>>>> out also, and just save stuff under "pkg" ?
>>>
> ...
>> I disagree. The path within the repository (with SVNROOT stripped)
>> describes exactly the location of the build description. Why
>> introduce artificial special cases? If the repository is
>> reorganized in some distant future all existing links will be
>> invalid are would need special treatment while retaining the full
>> path with revision will always link directly to the build recipe.
>
> I was thinking that stripping things out, should actually make things
> MORE portable, in the event of a reorganization.
>
> Take a starting point of $SVNROOT/csw/mgar/pkg/softname
>
> Then lets say it gets reorganized.
> There are two ways it might get reorganized, that I can see:
>  a) some way that is completely incompatible, ie:
>     $SVNROOT/csw/mgar/pkg/random/stuff/here/softname
>  b) some way that is auto-correctible. Example
>
>    $SVNROOT/something/else/pkg/softname.
>
> I was thinking that we are most likely to keep "pkg/softname".
>
>
> In which case, the web page would need only one consistent change to
> redirect people from
> the "old location", to the "new, up to date location".
>
> I guess it depends what your goals are. There would seem to be two,
> mutually conflicting goals:
>
> 1. Make it so packages already registered, do not have to be
> REregistered with new src locations, if we reorganize SVN
> (assumption: if we reorganize, we will do a clean, transparent
> migration of EVERYTHING, rather than onsey-twosy migrate)
>
> 2. Make it so packages keep the old legacy pathnames. So even if we
> reorganize, old packages keep pointing to old locations.
>
> I THINK Dago is aiming for #2.  Whereas it seems to me that #1 is  
> better.

Correct. The link should go to the specific revision in the repository  
the
package was built from. The reasoning is that releasable packages
should be build by an automatic build system in the future triggered
by copying trunk to a specific directory for releasable packages
which path will then go into the package. The path will be
different than the one leading to the most current build recipep

For the most up to date link the field can just
be freely editable, inference from a package field may or may not be
correct. It should be set manually by the package maintainer and may
be preset to trunk.


Best regards

   -- Dago