Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: alliance - Alliance VLSI CAD Sytem https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649 ------- Additional Comments From cgoorah@xxxxxxxxxxxx 2007-07-18 18:03 EST ------- (In reply to comment #7) > Whether both requiring alliance or both required by alliance, if you do so, > there is no interest in splitting them... I meant "both required by alliance. Ok, then I'll leave it as one package. > A good way to have multilibs compatibilty would be to have your prefix in > %{_libdir}/alliance (with datadir shared in %{_datadir}/alliance if relevant) I guess you haven't understood the contents of %{_datadir}/alliance. It contains the what so called in electronics "libraries" of different electronic components. These "libraries" have nothing to do with the daily word 'libraries' you used in the fedora packaging. Those electronic components does not depend on any architecture ( i386 , x86_64, ppc ). But however if I replace %{_datadir}/alliance by %{_libdir}/alliance, I fear I would break alliance further in terms of multilibs. We will have more bugs in alliance (which were not architecture ( i386 , x86_64, ppc ) dependent) which will vary from architecture to architecture. This is wrong and too risky! more info: Those electronic components are provided by alliance as a startup. However when a VLSI designer will use alliance, he/she will eventually use other electronic components. > 5 I mean the Menues indeed - I've experienced some problems whith packages that > do not handle this in %post, so i don't know if this is mandatory or should. > (depend if Minetype is present... anayway it seems not) The desktop files are very simple and they should be pulled up in the menus. There is no need you use %post or %postun for these desktop files. > 7 / indeed well that's a choice. But the variable "ALLIANCE_TOP" will even be used by the user in his/her working environment (as in any other commercial equivalent to alliance). Exporting ALLIANCE_TOP in the spec makes it more oblivious for debugging purposes, not by me but those who will be using this spec file for troubleshooting. Upstream and I were thinking to use this spec file in other fedora derivatives. In other words, it makes life easier for troubleshooting (maintainance)and share bugfixes between distros! > 9 / I still do not understand why you need to cp -pr them in "." since you do > uses thoses files but thoses present in doc/* those doc/* comes from %{__cp} -pr %{buildroot}%{prefix}/doc/ . Without %{__cp} -pr %{buildroot}%{prefix}/doc/, there is not doc/ directory. here the dot "." refers to the builddir, that is why it is in %files docs I specified only doc/* and not the absolute path. Its mainly experience talking here: _Suppose_ I patch in the Makefiles so that during %install the contents of documentation would not be copied into the buildroot. Then remove %{__cp} -pr %{buildroot}%{prefix}/doc/ as you suggested. And pull the docs ony be one on %file docs.: Each time upstream changes the makefiles or the contents of documentation/, I'll need to update my patch (eventually patches). Thus requiring me a lot of changes for each upstream release. And some contents are either not useful or duplicates (in terms of different format .pdf, .ps or .tex) The contents of the docs (in this case) have already undergone a "make" in the tex/ directories. So right now the pdfs are simply copied to the %buildroot. But if upstream decides to make a "make" during %__make in the future to produce those pdfs from texs, I'll need to dig further and further. This is frustrating. It is simple to let %__make finish, then gather the bits. You happend to see that I prefer everything being done in the SPEC file rather patching every single thing, in the end making life harder to debug or troubleshoot by me and others. > 16 / alliance-examples would be fine as the content is really differents than > -docs... (for example -docs may not requires main whereas examples will requires > it - because examples may live in %{_datadir}/alliance ) hmm the release 1 might say so, because I missed some other directories in tutorials. In release 2, you will see that some docs come with its _own_ examples. :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review