>>>>> "IU" == Iñaki Ucar <iucar@xxxxxxxxxxxxxxxxx> writes: IU> - Version: As you already found out, there are many version formats IU> allowed. But it's easy to work from Version: in the normal case and simply allow the CRAN version to be specified separately, as I showed in the R-uuid sample. If it's rather more common that updating the version in two places is a burden, we can certainly look at other ways to do it. IU> - Arch, Requires, BuildRequires, libdir/datadir: As Elliott pointed IU> out already, archful packages can be detected just by looking into IU> the DESCRIPTION file, by checking whether the NeedsCompilation flag IU> exists. As nim pointed out in a previous message, it's "not possible" to make use of this information for many things as long as DESCRIPTION is within the tarball, because unpacking does not happen until well after specfile parsing (and thus macro expansion) has happened. (Technically all things are possible but there isn't too much you can do with a source file before it's even been downloaded, and we certainly have to be able to parse the spec before that point.) There are of course some things you can do. The %prep and %install scriptlets, for example, are just shell code which can be inserted by macros but which actually runs much later. So you can use that information to figure out how to build, and what files to install. But you can't look in there to add BuildArch: noarch or add build dependencies because those have to be done much earlier. So that's why I just provided separate macros for the archful and noarch cases. IU> - %prep, %build, %install, %check, %files: These can be automated IU> too. Well, look at the two examples I provided. The %files list isn't completely consistent (one package has COPYING and the other doesn't) but the test macro file I provided conditionalizes this properly. IU> I'm not familiar at all with RPM macros, but I can help with all IU> these details. So then perhaps have a look at those examples I provided and see how they would actually work in real life on more than the two specs I converted. If I get time today I'll fill things in for the noarch package case. - J< _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
