Directory structure and version conflicts

Fabricio Cannini fcannini at gmail.com
Wed May 22 17:30:18 UTC 2013


Em 22-05-2013 01:46, Jeffrey Johnson escreveu:

Hi Jeffrey !

>> ====
>>
>> /opt
>>     /{ softwares,libraries,compilers }
>>         /software_name
>>             /software_version
>>                 /compiler_name
>>                     /compiler_version
>>
>
>   A hierarchy like this has certain performance consequences,
> particularly with may identifal directory names.
>
> Rather than using a hierarchy like
> 	.../foo/bar/baz/...
> try flattening the structure using something string separator. E.g if
> you chose '-' as a separator, then the equivalent would be
> 	.../foo-bar-baz/...
> with fewer sub-directories and essentially the same identifiers.


Funnyly, I was thinking of an alternative structure just like you said:

/opt
     /{ softwares,libraries,compilers }
         /software_name-software_version
             /compiler_name-compiler_version


>> ====
>>
>> Also, i'm thinking of embedding compiler vendor and version on the 'release' field of the rpm .
>>
>
> As Panu just said, Release: is being abused for all sorts of token identifiers,
> adding compiler vendor/version adds complexity for modest gain.
>
> One can add suffixes to the package Name:, but you will have fairly large
> identifiers for all your packages no matter whether Name: or Release: is
> overloaded with identification tokens.
>
> One simple way out is to add
> 	Provides: compiler-vendor-version
> and then construct a compound --queryformat to extract the additional info when needed.


Using 'Provides:' would not save me from, say, putting 
'compiler_name-compiler_version' in 'Name:' to differentiate similar 
packages, would it ?


More information about the Rpm-list mailing list