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 ?
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
