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

Dagobert Michelsen dam at opencsw.org
Mon Nov 15 19:20:58 CET 2010


Hi Phil,

Am 15.11.2010 um 18:32 schrieb Philip Brown:
> within the context for that only --
> For that, the actual database space could be somewhat fixed.
> After all, we are now agreed that package names should be 31 chars or less.

Does that mean all my waiting packages get released now including the Perl
modules with longer names than previously allowed but <31?

> And that the location for a package in our repository is usually
> [top]/softwarename
> Or in some rare cases (which I'd personally like to do away with)
> [top]/(maybe-ONE subdir)/softwarename
> 
> So we could actually pick some reasonable fixed size for it. The exact
> length, would depend on the answer to your followup question:
> 
>> I also think that the common portion of the SourceForge.net URL should
>> be stripped out of the storage here and appended by php as a
>> statically defined string in the code.
> 
> Are you suggesting that the existing string in pkginfo be left as is,
> but when inserted into the database, we auto-strip out {top of
> repository} ?
> 
> sounds potentially reasonable.
> 
> If so, then the database size for storing the OPENCSW_REPOSITORY info
> could be limited to
> 31 + fileseparator + 31 = 63.   Make it 64 just to be 'rounded'
> 
> hmmm?

Nope. The server name prefix to the repository should be stripped
up to the repository root, which is
  Repository Root: https://gar.svn.sf.net/svnroot/gar
The path length is not directly connected to the catalog-, nor
the package name, but the upstream name which may or may not
be similar in length. Short answer: Just user 255 and we never
will have this discussion again :-) If you have doubts about the
database size: an extra GB of RAM shouldn't matter which will
suffice for about 1.000.000.000 / (255 - 63) ~ 5 million
extra package. Some room available :-)


Best regards

  -- Dago




More information about the maintainers mailing list