Currently the local content spec file has extension .txt e.g: Content_Spec_Processor_Guide-post.txt The .txt extension doesn't make it clear what the file is. I thought it was a README type file until I opened it. What about using the .spec extension? So it would be: Content_Spec_Processor_Guide-post.spec Then it becomes kind of self-documenting what it is...
can't do this sorry as the RPM files already use the .spec file extension. Perhaps a .contentspec but then that seems rather long for a file extension.
<lnewson> btw jwulf in regards to https://bugzilla.redhat.com/show_bug.cgi?id=803162 <lnewson> I can't use .spec is is already taken as a file extension <lnewson> which is why i changed it back to .txt <lnewson> we could do .contentspec <lnewson> and lol nice qoute <jwulf> oh yeah, rpm spec files <jwulf> .cspec ? <jwulf> although .contentspec is less ambiguous <jwulf> My_Book-post.contentspec <jwulf> is fully self-documenting <jwulf> i can see the manual entry now: <jwulf> "My_Book-post.contentspec" is exactly what it purports to be - the post-processed content spec for My_Book <jwulf> :-) <jwulf> sounds good <lnewson> yeah my only concern was it seems rather long for a file extension <lnewson> and i'd thought the same about .cspec <jwulf> it does, hence my first thought of cspec <jwulf> but it's unambiguous <jwulf> self-evident <jwulf> and the user should hardly ever have to type it <jwulf> they never have to create that file <jwulf> and they hardly ever have to use its name explicitly <jwulf> so i think on balance the clarity outweighs the length
Added in 0.22.3 The client will still check for .txt files when using the push and status commands for compatibility with previous versions.
Verified with cspclient-0.23.2-1.