[Bug 248649] Review Request: alliance - Alliance VLSI CAD Sytem

[bugzilla at redhat.com]

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 at yahoo.com.au  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.