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

Philip Brown phil at bolthole.com
Wed Nov 17 18:49:08 CET 2010


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.


More information about the maintainers mailing list