Ciaran McCreesh wrote: > Because that would be introducing a new, non-extensible, inflexible > requirement upon the content of ebuilds, and the goal of EAPI is to > avoid doing exactly that. >
If you're putting all this metadata in the filename, I'm not sure how you can distinguish between the filename and the content regarding flexibility. If anything I'd rather have more flexibility in filenames and less in content. For example, cat/pkgname/version could be a whole lot more flexible if they were just a string and didn't have to be parsed out of the concatenated fields in the filename. Mind you, I'm not proposing this, but it seems like putting yet another concatenated field in the filename is only going to make the filenames that much more complicated. Unless you're going to make ebuilds semi-machine-built objects like xml files it is going to be hard to make them completely flexible without having package managers with a bazillion cases in them for parsing the files. That will naturally limit support for lots of EAPIs. I do agree with your goals - it just seems like there HAS to be a better way of doing it than putting something at the end of the filename.
smime.p7s
Description: S/MIME Cryptographic Signature
