[csw-maintainers] Final feedback for putting in GAR/repository info into our mysql db

Dagobert Michelsen dam at opencsw.org
Fri Nov 19 10:02:00 CET 2010


Hi Phil,

Am 18.11.2010 um 20:45 schrieb Philip Brown:
>> Am 17.11.2010 um 18:49 schrieb Philip Brown:
>>> I guess it depends what your goals are. There would seem to be two,
>>> mutually conflicting goals: [for db registration of  
>>> OPENCSW_REPOSITORY]
>>>
>>> 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)
>
> [ http://blahblah/svnroot/gar/csw/mgar/pkg/ruby/trunk@11004
> becomes pkg/ruby/trunk at 11004, or even just ruby/trunk at 11004, in db ]
>
>>>
>>> 2. Make it so packages keep the old legacy pathnames. So even if we
>>> reorganize, old packages keep pointing to old locations.
>
> [ http://blahblah/svnroot/gar/csw/mgar/pkg/ruby/trunk@11004
> becomes gar/csw/mgar/pkg/ruby/trunk at 11004 in db]

Almost... It becomes
   csw/mgar/pkg/ruby/trunk at 11004
as the repository root is https://gar.svn.sf.net/svnroot/gar. This  
allows
relocation of the repository as a whole if necessary while keeping the
complete information to find the package in the repository tree.

>>> 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.
>
> Okay. Well, I dont feel strongly that there is one particular "right"
> answer; I think its mostly just "what do people want".

Or maybe both.

> Putting this out there, with a clean subject line so people previously
> ignoring it, might pay attention now :)
> If there's no other feedback in support of the shorter method, then I
> guess I'll start working on implementing the longer method come monday
> (nov 22nd)

Great!


Best regards

   -- Dago


More information about the maintainers mailing list