Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=675557 --- Comment #11 from BjÃrn Persson <bjorn@xxxxxxxxxxxxxxxxxxxx> 2011-04-24 07:41:59 EDT --- Â I see that you added /usr/include/matreshka to the base package. I think matreshka-devel is the best package to put this directory in, because only -devel subpackages have files under /usr/include/matreshka and they all depend on matreshka-devel (directly or indirectly). The way it is now, there will be an empty and unnecessary /usr/include/matreshka directory when the compiled libraries are installed but the -devel packages are not. It's not a big issue though. Â I had to add quotes in the export command to get the build to work, like this: export GPRBUILD_FLAGS="%{GNAT_optflags}" Without the quotes Bash set GPRBUILD_FLAGS to "-cargs" and then tried to export variables named "-O2", "-g" and so on. Â Even with the quotes, the parameters from GNAT_optflags weren't passed to GCC and Gnatlink. I tried making GPRBUILD_FLAGS a parameter to Make instead of an environment variable, and then the parameters were passed correctly. Apparently you'll need to make more changes to the makefiles if you want them to pick up this variable from the environment. Â The build log in Koji shows GPRBUILD_FLAGS being passed to Make as a parameter. Obviously the package you submitted to Koji was different from the one you linked to here, despite the version and release numbers being the same. Don't do that. Â You're neglecting the changelog. Every time you make changes to the package you should increment the release number and write a new changelog entry. Â The project files have too generic names. Project file names are a shared namespace that we need to be careful not to pollute. A name like "sql.gpr" is too prone to collisions. It would be a good name if there were one library that could claim to be *the* SQL library for Ada, but that's not the case. There are several database interface libraries and it wouldn't be fair to let one of them claim the name "SQL". "fastcgi.gpr" is a similar case. Somebody might want to package another library that also implements the FastCGI interface, and there's no reason why one library should have a greater right to that name than another. To prevent name collisions the Ada packaging policies we wrote state that either the name of the library must be included in the filenames of the project files (that is, "matreshka_sql.gpr" or something similar), or else they must be in a subdirectory named after the library (in which case other projects would use Âwith "matreshka/sql.gpr";Â et cetera to import them). Whether you change the names or use a subdirectory, it would be best if this change were made upstream so that the project files can be referred to in the same way in all distributions that include Matreshka as well as when users download the source package and compile it themselves. Otherwise project files will have to be patched left and right. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review