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