Bug 248649 - Review Request: alliance - Alliance VLSI CAD Sytem
Review Request: alliance - Alliance VLSI CAD Sytem
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nicolas Chauvet (kwizart)
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-17 17:23 EDT by Chitlesh GOORAH
Modified: 2008-11-10 11:56 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-13 18:14:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
kwizart: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)
rpmlint alliance (release 4) - problem with shlib (151.78 KB, text/plain)
2007-07-27 07:45 EDT, Nicolas Chauvet (kwizart)
no flags Details

  None (edit)
Description Chitlesh GOORAH 2007-07-17 17:23:46 EDT
Spec URL: http://tux.u-strasbg.fr/~chit/alliance/F-8/alliance.spec
SRPM URL: http://tux.u-strasbg.fr/~chit/alliance/F-8/alliance-5.0-1.fc8.src.rpm
Description:
Alliance is a complete set of free CAD tools and portable libraries for
VLSI design. It includes a VHDL compiler and simulator, logic synthesis
tools, and automatic place and route tools.

A complete set of portable CMOS libraries is provided, including a RAM
generator, a ROM generator and a data-path compiler.

Alliance is the result of more than ten years effort spent at ASIM department
of LIP6 laboratory of the Pierre et Marie Curie University (Paris VI, France).

Alliance has been used for research projects such as the 875 000 transistors
StaCS superscalar microprocessor and 400 000 transistors IEEE Gigabit HSL
Router.

Alliance provides CAD tools covering most of all the digital design flow:

 * VHDL Compilation and Simulation
 * Model checking and formal proof
 * RTL and Logic synthesis
 * Data-Path compilation
 * Macro-cells generation
 * Place and route
 * Layout edition
 * Netlist extraction and verification
 * Design rules checking
Comment 1 Nicolas Chauvet (kwizart) 2007-07-17 17:33:57 EDT
Starting review...
Comment 2 Chitlesh GOORAH 2007-07-17 17:45:39 EDT
Some notes about this package:
#1: this is a Hardware Development CAD. The headers included in the main 
package are not an error or a mistake, but useful for some %_bindir/*. In 
other words, it is important for the working(normal) environment of the user.
(note: don't get confuse with headers of a normal application and the hardware 
CAD)

#2: The design tools at %_bindir/* are used in a collectively way following 
the design flow.
http://www-asim.lip6.fr/recherche/alliance//doc/design-flow/flow.html
If one of the %_bindir/* is buggy it may affect the entire design flow.

#3: I wrote a simple tutorial for trial:
http://chitlesh.googlepages.com/full_adder_alliance

#4: Alliance depends heavily on %{prefix} (careful not %{_prefix}). Most of 
the sources have hardcoded paths to %{prefix}. Patching the dozens of 
Makefiles isn't enough.

#5: Makefiles on the -doc
Makefiles are present in alliance-examples/*. It is normal because
 * it gives the VLSI designer a template on how to create his own
   Makefile for alliance (VLSI designers normally don't know how to do so)
 * it is not part of the build, but part of the _working_ environment of the 
user

#6: on the build.log there are lines about :
libtool: install: warning: 
`/builddir/build/BUILD/alliance-5.0/mbk/src/libMut.la' has not been installed 
in `/usr/lib'
I have no idea what to do with it. Any suggestion is welcome.
http://tux.u-strasbg.fr/~chit/alliance/F-8/build.log

I tried to comment as much as I can on the SPEC file.
Comment 3 Nicolas Chauvet (kwizart) 2007-07-17 21:53:30 EDT
Ok so few comments to start:
1 / prefix seems problematic. But since no arch dependant files are installed in
it, this could be fine if we can have configs files in /etc actually...
Also no %config(no replace) seems to be used for users config files...

2 / evr problem
The source has 20060509 but this do not appear in evr wheras this should appear
inside the release tag (if release, then >= 1). Others sources have the same
version (in OLD_RELEASES ). So this will need to add 20060509snap in the release
field to make a difference.

3 / URL has changed to http://www-asim.lip6.fr/recherche/alliance/

4 / patches macros. 
- As the pacakge name is good why do you need to uses %{name}? this bring some
confusion when looking for the patch instead of having the full name.
- Some patches are backport from older version (+ is older than -) This mean
that some patches could be usefull with later release ? I cannot see the aim of
using %{version} in this case! Unless it will break patch historicy in cvs if no
changes are made to the patch for later releases.

5 / desktop files
 * You missed 
Requires(post): desktop-file-utils
Requires(postun): desktop-file-utils
 * I don't know if the shortcuts will be in the right category... 
 * see scriplets - 11 /

6 / About the kindly requested
https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00750.html
Why do you choose not to show the "kindly requested" in %description ?

7 / %configure
 * This package do not conform to the standard paths and use a prefix with
--with-alliance-top=%{prefix}. But, do you need to export it to make it work ?
 * --disable-static is avaible why don't you uses it ? Does it works ?

8 / # applying timestamps
What do you mean by this ? This could go in %prep for Source7

9 / # documentation
Why do you copy them it "." ? (you do not seems to use them after that...)
It could be safer to copy all of them in a created __doc - This will need to be
remove just before %install like:
%{__rm} -rf %{buildroot} __doc

10 / #conflicts with man-pages and is a duplicate of log.1.gz
This make rise the problem of too much generic names appear (Which I haven't
checked yet). Maybe a renamed could be enought if the --program-prefix do not
work if this apply.

11 / scriplets
  * %preun -p  /sbin/ldconfig - This is unneeded
  * Recommand to have this if desktop file has a MimeType key.
%post
/sbin/ldconfig
update-desktop-database &> /dev/null || :

%postun
/sbin/ldconfig
update-desktop-database &> /dev/null || :

12 / # duplicate and unstripped-binary-or-object
%exclude %{_libdir}/debug
 * This is wrong on x86_64 and also uneeded (tested)

13 / %{_includedir}/*
  * header are presents in main but not in devel - Is it possible to sort those
that should be used at runtime from those that are needed for developping alliance ?

14 / %{_mandir}/man?/*
 * Check if some of them shouldn't go in -devel

15 / #Makefiles are present in alliance-examples/*
  * Is it possible to have another sub-package for these examples (which will
follow others rules of Requirement eventually )
  * Having users to build them is %doc directory is not fair - Thoses can go in
%{_datadir}/alliance/examples.

16 / build fails on x86_64 FC6: (i will give a retry )
/usr/bin/ld: cannot find -lMvg
collect2: ld returned 1 exit status
make[2]: *** [x2vy] Error 1
make[2]: *** Waiting for unfinished jobs....
Comment 4 Chitlesh GOORAH 2007-07-18 05:30:54 EDT
(In reply to comment #3)
> Ok so few comments to start:
> 1 / prefix seems problematic. But since no arch dependant files are 
installed in
> it, this could be fine if we can have configs files in /etc actually...
> Also no %config(no replace) seems to be used for users config files...

Would you like me to put configs files in /etc and just create a symbolic link 
to /usr/share/alliance/etc ?
Note: without this link some %_bindir/* would be broken since this path is 
hardcoded into the sources.

> #2  #3
Ok, will change appropriately.

> 4 / patches macros. 
> - As the pacakge name is good why do you need to uses %{name}? this bring 
some
> confusion when looking for the patch instead of having the full name.
> - Some patches are backport from older version (+ is older than -) This mean
> that some patches could be usefull with later release ? I cannot see the aim 
of
> using %{version} in this case! Unless it will break patch historicy in cvs 
if no
> changes are made to the patch for later releases.

They will break in cvs since upstream

Patch0:        %{name}-%{version}-addphcon.patch

There are 2 bugs in this release: (on ocp and on boog)
As for ocp, I've backported to the old release (20060218), till there is a 
fix.
Concerning boog, upstream will be digging on it this week:
https://www-asim.lip6.fr/wws/arc/alliance-users/2007-07/msg00017.html

Patch1:        %{name}-%{version}-examples.patch
        (is for the documentation/alliance-examples folder)
Patch2:        %{name}-%{version}-run.patch
        (is for the documentation/alliance-run folder)
Patch3:        %{name}-%{version}-perms.patch
        (setting the proper permissions)

will be without %{version}.

> 5 / desktop files
>  * You missed 
> Requires(post): desktop-file-utils
> Requires(postun): desktop-file-utils

As agreed if MimeType key in desktop files is used, and will be using in the 
next release.

>  * I don't know if the shortcuts will be in the right category... 

You mean in the menus ?


> 6 / About the kindly requested
> https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00750.html
> Why do you choose not to show the "kindly requested" in %description ?

There is no big reason behind it, except I had already agreed with upstream on 
a separate file before Tom proposed.
The %description would be too long. I've included it into a separate file 
alliance.fedora. If you want me to change accordingly, I can do it.

> 7 / %configure
>  * This package do not conform to the standard paths and use a prefix with
> --with-alliance-top=%{prefix}. But, do you need to export it to make it 
work ?

You mean 
 - export ALLIANCE_TOP=%{prefix}
 - %configure --prefix=%{prefix} --enable-alc-shared --disable-static
 + %configure --prefix=%{prefix} --enable-alc-shared 
\ --disable-static --with-alliance-top=%{prefix}
?


>  * --disable-static is avaible why don't you uses it ? Does it works ?

will use
 
> 8 / # applying timestamps
> What do you mean by this ? This could go in %prep for Source7

will move to %prep

> 9 / # documentation
> Why do you copy them it "." ? (you do not seems to use them after that...)

I need them in the -doc package. 

> 10 / #conflicts with man-pages and is a duplicate of log.1.gz
> This make rise the problem of too much generic names appear (Which I haven't
> checked yet). Maybe a renamed could be enought if the --program-prefix do 
not
> work if this apply.

It is a duplicate of log.1.gz as well. I see no harm removing a duplicate.

> 11 / scriplets
>   * %preun -p  /sbin/ldconfig - This is unneeded
>   * Recommand to have this if desktop file has a MimeType key.
> %post
> /sbin/ldconfig
> update-desktop-database &> /dev/null || :
> 
> %postun
> /sbin/ldconfig
> update-desktop-database &> /dev/null || :

Will  use MimeType key

> 12 / # duplicate and unstripped-binary-or-object
> %exclude %{_libdir}/debug
>  * This is wrong on x86_64 and also uneeded (tested)

On i386, I have debug files before the script /usr/lib/rpm/find-debuginfo.sh
Is there a way to disable this thing and let /usr/lib/rpm/find-debuginfo.sh do 
the job ?

> 13 / %{_includedir}/*
>   * header are presents in main but not in devel - Is it possible to sort 
those
> that should be used at runtime from those that are needed for developping 
alliance ?

will try

> 14 / %{_mandir}/man?/*
>  * Check if some of them shouldn't go in -devel

will try

> 15 / #Makefiles are present in alliance-examples/*
>   * Is it possible to have another sub-package for these examples (which 
will
> follow others rules of Requirement eventually )
>   * Having users to build them is %doc directory is not fair - Thoses can go 
in
> %{_datadir}/alliance/examples.

Ok, will be opting for a "alliance-examples" sub package.

> 16 / build fails on x86_64 FC6: (i will give a retry )
> /usr/bin/ld: cannot find -lMvg
> collect2: ld returned 1 exit status
> make[2]: *** [x2vy] Error 1
> make[2]: *** Waiting for unfinished jobs....

Are you using %{__make} %{?_smp_mflags} ?
Comment 5 Chitlesh GOORAH 2007-07-18 05:37:06 EDT
reply to comment #4)
> (In reply to comment #3)
> > 5 / desktop files
> >  * You missed 
> > Requires(post): desktop-file-utils
> > Requires(postun): desktop-file-utils
> 
> As agreed if MimeType key in desktop files is used, and will be using in the 
> next release.

Actually, I mean "will _not_ be using".

> > 11 / scriplets
> >   * %preun -p  /sbin/ldconfig - This is unneeded
> >   * Recommand to have this if desktop file has a MimeType key.
> > %post
> > /sbin/ldconfig
> > update-desktop-database &> /dev/null || :
> > 
> > %postun
> > /sbin/ldconfig
> > update-desktop-database &> /dev/null || :
> 
> Will  use MimeType key

Again, will _not_ be using.


> > 15 / #Makefiles are present in alliance-examples/*
> >   * Is it possible to have another sub-package for these examples (which 
> will
> > follow others rules of Requirement eventually )
> >   * Having users to build them is %doc directory is not fair - Thoses can 
go 
> in
> > %{_datadir}/alliance/examples.
> 
> Ok, will be opting for a "alliance-examples" sub package.

After a second thought, does it make sense to have a sub package ? I'll be 
leaving it in -doc package
Comment 6 Chitlesh GOORAH 2007-07-18 15:53:11 EDT
You will laugh at me, but the %{_libdir}/*.so is also required by the main 
package.

I was thinking about having 2 more sub-packages in order to comply with the 
packaging guidelines:
-   alliance-lib for %{_libdir}/*.so, and
-   alliance-headers for %{_includedir}/*
both requiring alliance.

what do you think ?
Comment 7 Nicolas Chauvet (kwizart) 2007-07-18 16:48:10 EDT
Whether both requiring alliance or both required by alliance, if you do so,
there is no interest in splitting them...
Actually -libs sub-packages are used to provide multibs compatibily on lib64
systems. This needed to have Requires %{main}-libs = %{evr} for -devel, but
that's all. 
- If you uses Requires %{main}-libs on main, this only requires something that
rpm would discover by itself...
- If you uses Requires %{main} on -libs, then you will break multilibs
compatibilty because you will bring i386 binaries into x86_64 repository (and
binaries will share the same namespace in %{_bindir} which is wrong )

A good way to have multilibs compatibilty would be to have your prefix in
%{_libdir}/alliance (with datadir shared in %{_datadir}/alliance if relevant)

About headers, If you can sort them, you can have %{_libdir}/alliance/include
for runtime (with main ) and %{_includedir}/alliance for devel (or runtime
headers in datadir - but i expect it will break some alliance_top prefix ?!)

That could be a good idea if you can uses relative path to find headers to have
them in %{_datadir}/alliance/include if you have examples in
%{_datadir}/alliance/examples , maybe...)

More Answears:
1 / leave this as is work for now...
4 / If upsteam change the name of the patches, you will need to import them into cvs
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)
7 / indeed
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/*
10 / Can you see at which step this /usr/lib/debug directory is created in
build.log ?

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 )



Comment 8 Chitlesh GOORAH 2007-07-18 18:03:24 EDT
(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. :)

Comment 11 Chitlesh GOORAH 2007-07-24 06:26:54 EDT
Ping ?
Comment 12 Nicolas Chauvet (kwizart) 2007-07-24 12:23:06 EDT
Review of version - release : 5.0-3.20070718snap
* From Previous comments:
- multilibs, As there is no more -devel package, the multilibs problems on
repository is solved. This mean there is no headers to write plugins for
alliance ? Then OK.

- 5 Ok for not using desktop-file-utils. But on my Gnome environnement, the
menues are showed in Edutainment which is not a right name in my view (mostly
because it is not translated)
Also X-Desktop-File-Install-Version=0.10 in sources desktop files is wrong. This
field is added at install time..Be carefull that desktop-file-install in F8
rawhide is no more permissive with theses littles errors. (not tested yet...)

- 7 / 9 / 16 : OK

- Still i don't understand why you used macro for name of patches.
  That might be better to have them in full name (as the name will not change)

* New comments: (now it builds in mock on x86_64)
(rpmlint on rpm packages )
- Names are too generic. For headers in %{_includedir}/*.h and libraries in
%{_libdir}/*.so, maybe you can at least uses a subdirectory with them (and put a
path for in /etc/ld.so.conf.d )
When trying to install it:  
-----------
le fichier /usr/include/btr.h de l'installation de
alliance-5.0-3.20070718snap.fc6 entre en conflit avec le fichier du paquetage
mx-2.0.6-2.2.2
le fichier /usr/share/man/man3/log.3.gz de l'installation de
alliance-5.0-3.20070718snap.fc6 entre en conflit avec le fichier du paquetage
man-pages-2.39-7.fc6
----------

- E: alliance non-executable-script /etc/alliance/attila.conf 0644
  See why this is considered as script (may be safe to ignore...
  Also, maybe not all files in /etc/%{name} will need %config(no replace)
  This can be better to have only %{config} for some of them. For example if
they are changing between release and need to be updated with no user choice...
 For files that depend on users choice , the better way could be to have files
to be sourced in a sub-directory... (maybe not relevant, in this case...)

- W: alliance non-conffile-in-etc /etc/alliance/alc_env.csh
  Not sure it is the right place for it...?! why this have changed from profiles.d ?

(rpmlint on installed file : rpmlint alliance )
- Untested - (package cannot be installed becaue mx is in use)

 
Comment 13 Chitlesh GOORAH 2007-07-24 15:47:13 EDT
(In reply to comment #12)
> Review of version - release : 5.0-3.20070718snap

> - 5 Ok for not using desktop-file-utils. But on my Gnome environnement, the
> menues are showed in Edutainment which is not a right name in my view 
(mostly
> because it is not translated)

All scientific apps of fedora are placed at that location:
* ktechlab
* geda/gaf
* magic
* xcircuit
* qucs
* labplot
(to name a few)

>   Not sure it is the right place for it...?! why this have changed from 
profiles.d ?

It has always been this way, i.e in all my releases there were 2 symbolic 
links on /etc/profile.d
In my previous releases, the alc_env* scripts were at /usr/share/alliance/etc, 
in the release 3 they were moved to /etc/allliance.


I'll include your other comments in the release 4.
Comment 15 Nicolas Chauvet (kwizart) 2007-07-27 07:39:48 EDT
* rpmlint on package: (only one of each)
W: alliance devel-file-in-non-devel-package /usr/share/alliance/include/msl.h
As taken as a compiler, this is acceptable, the path in acceptable also...
W: alliance devel-file-in-non-devel-package /usr/share/alliance/lib/libCtp.so
This one also, as this is not arch dependant...but this may lead to problem later...

But:
E: alliance arch-dependent-file-in-usr-share /usr/share/alliance/lib/libBtr.so.1
.0.3
This one is wrong - This would be better to have them in libdir/alliance (with
the previous symlink as i expect, it will be easier to have them in the same
directory).

Also maybe this is related to our shlib problem we discussed on #IRC: "libtool:
install: warning: `/builddir/build/BUILD/alliance-5.0/abt/src/libAbt.la' has not
been installed in `/usr/share/alliance/lib'"
Does the .la source file exist ?

Here are the output of "rpmlint alliance" on installed files:
This is sometime the result of missing libraries LDFLAGS
(see attachment)


Also i wonder if the  binaries aren't subject to the same problem with generic
names...(i have'nt checked this...)


Comment 16 Nicolas Chauvet (kwizart) 2007-07-27 07:45:04 EDT
Created attachment 160109 [details]
rpmlint alliance (release  4) - problem with shlib

See if unused-direct-shlib-dependency and undefined-non-weak-symbol can be
solved by adding the right links LDFLAGS for each library (or if this
information have been lost during the prep of the build process...)
Comment 18 Chitlesh GOORAH 2007-08-01 06:47:37 EDT
ping ?
Comment 19 Nicolas Chauvet (kwizart) 2007-08-01 08:53:23 EDT
Looking at build.log: This append in the %prep section
 * "/usr/share/texmf/web2c/mktexupd: /var/lib/texmf/ls-R unwritable."
Maybe, there is something to change with this file in %post (%postun ), so the
changes it tries to write, will be done in %post (if ever usefull...)
 * "Overfull \hbox (29.40456pt too wide) in paragraph at lines 258--260
[]\T1/bch/b/n/10 GRAAL \T1/bch/m/n/10 uses the en-vi-ron-ment vari-able \T1/bch
/b/n/10 GRAAL_TECHNO_NAME\T1/bch/m/n/10 . It must be set to \T1/bch/b/n/10 /al-
liance/etc/cmos.graal\T1/bch/m/n/10 . "
See if there is something to change with paths
 * "No file start.aux. / synthesis.aux." 

* Files names are too generic: I still have a problem with theses files to be
installed in _bindir as they are too generics... Is it possible to have prefixed
named ?
Another solution could be to uses bin in %{_libdir}/alliance/bin, then add the
Path of the alliance binaries... (see the next comment about profile.d/alc_env.sh )

/usr/bin/a2def
/usr/bin/a2lef
/usr/bin/alcbanner
/usr/bin/asimut
/usr/bin/b2f
/usr/bin/boog
/usr/bin/boom
/usr/bin/cougar
/usr/bin/def2a
/usr/bin/dreal
/usr/bin/druc
/usr/bin/exp
/usr/bin/flatbeh
/usr/bin/flatlo
/usr/bin/flatph
/usr/bin/flatrds
/usr/bin/fmi
/usr/bin/fsp
/usr/bin/genlib
/usr/bin/genpat
/usr/bin/graal
/usr/bin/k2f
/usr/bin/l2p
/usr/bin/loon
/usr/bin/lvx
/usr/bin/m2e
/usr/bin/mips_asm
/usr/bin/moka
/usr/bin/nero
/usr/bin/ocp
/usr/bin/pat2spi
/usr/bin/pdv
/usr/bin/proof
/usr/bin/ring
/usr/bin/s2r
/usr/bin/scapin
/usr/bin/sea
/usr/bin/seplace
/usr/bin/seroute
/usr/bin/sxlib2lef
/usr/bin/syf
/usr/bin/vasy
/usr/bin/x2vy
/usr/bin/x2y
/usr/bin/xfsm
/usr/bin/xpat
/usr/bin/xsch
/usr/bin/xvpn

 * alc_env.csh and alc_env.sh should be marked as %config (no replace do not
seems to usefull in this case)
  @DATE@ - this macro isn't expanded...

  # System environment variables.
 PATH=$ALLIANCE_TOP/bin:$PATH
 export PATH
 * As previously talked with the prefix discution. $ALLIANCE_TOP is not arch
independant from how upstream use it. So linking /usr/share/alliance/lib to
/usr/lib64/alliance seems wrong (I expect it might be needed by the makefiles,
is not, please remove this symlink). 
 Thats because $ALLIANCE_TOP is not arch independant, that I would prefer to
uses %{_libdir}/alliance (then using symlinks to /usr/share/alliance/$i from
/usr/lib64/alliance/$i with $i as arch independant data - This seems more
correct to me...)

 * There might be some testing todo with selinux... (then ask the
selinux-policy-maintainer to add special context if this is needed...)
Comment 20 Chitlesh GOORAH 2007-08-01 09:35:40 EDT
(In reply to comment #19)
> Looking at build.log: This append in the %prep section
>  * "/usr/share/texmf/web2c/mktexupd: /var/lib/texmf/ls-R unwritable."
> Maybe, there is something to change with this file in %post (%postun ), so 
the
> changes it tries to write, will be done in %post (if ever usefull...)
>  * "Overfull \hbox (29.40456pt too wide) in paragraph at lines 258--260
> []\T1/bch/b/n/10 GRAAL \T1/bch/m/n/10 uses the en-vi-ron-ment vari-able 
\T1/bch
> /b/n/10 GRAAL_TECHNO_NAME\T1/bch/m/n/10 . It must be set to 
\T1/bch/b/n/10 /al-
> liance/etc/cmos.graal\T1/bch/m/n/10 . "
> See if there is something to change with paths
>  * "No file start.aux. / synthesis.aux." 
> 

These are for pdf generation. That is for documentation.

The "unwritable" warning has no influence on the final pdf and also 

chitlesh(~)[0]$rpm -qf /var/lib/texmf/ls-R
tetex-fonts-3.0-34.fc6
chitlesh(~)[0]$rpm -qf /usr/share/texmf/web2c/mktexupd
tetex-fonts-3.0-34.fc6

Documentation produced are used as tutorials and have nothing to do with 
modifying files from tetex-fonts.
Comment 21 Chitlesh GOORAH 2007-08-01 12:09:22 EDT
(In reply to comment #19)
>  * As previously talked with the prefix discution. $ALLIANCE_TOP is not arch
> independant from how upstream use it.

chitlesh(~)[0]$ll /usr/share/alliance/
total 4
drwxr-xr-x 10 root root 4096 Jul 29 17:55 cells
lrwxrwxrwx  1 root root   21 Jul 29 17:55 etc -> ../../../etc/alliance
lrwxrwxrwx  1 root root   29 Jul 29 17:55 
include -> ../../../usr/include/alliance
lrwxrwxrwx  1 root root   25 Jul 29 17:55 lib -> ../../../usr/lib/alliance

The symbolic links are here to protect hardcorded bits of the codes that 
aren't dynamically set up during %configure. These symbolics links are here to 
meet _functionality_ when all the %{_bindir}/* are used at once( on a Makefile 
for example.) 

Please take note that libraries are placed at %{_libdir}/%{name} 
during %configure --libdir=%{_libdir}/%{name}

As from the only "real" directory, cells which contains "technology files". 
Text files which specify the design rules of the respective technology.

The latter is _NOT_ a must in the alliance distribution. Since the user might 
want to use his/her technology. for example from:
* http://www.vlsitechnology.org/
* commercial technologies

However the included cells are present so that one who doesn't have his/her 
own technology can use them for the first time.

I hope I clarified that this is not arch-dependent, and should not 
be %{_libdir} but %{_datadir}

Please also note, that once alliance is in the fedora collection, i'll start 
packaging the standard cells from http://www.vlsitechnology.org/, hence those 
will be placed in  %{_datadir}, since there are only text files and images. 
Thus _not_ arch-dependent.

The way that upstream uses the $ALLIANCE_TOP variable is similar to most 
commercial vendors do.

But in my spec, these are split up in standard linux directories and made sure 
that users can still use $ALLIANCE_TOP. This variable IS NOT only for 
packagers or developers but users as well.
Comment 22 Chitlesh GOORAH 2007-08-01 12:10:49 EDT
(In reply to comment #19)
>  * There might be some testing todo with selinux... (then ask the
> selinux-policy-maintainer to add special context if this is needed...)

Is there any reason why alliance might require selinux policies ?
Comment 24 Nicolas Chauvet (kwizart) 2007-08-12 09:54:34 EDT
OK
Exept for the cells (and all arch independant data) that should be in
/usr/share/alliance, thoses directories seems rights...
The aim is to sort arch dependant and arch-independant data.

But the remaining problems is about $alliance_top/{etc,cells,...}, Actually
thoses directory are hardcoded in configure* and Makefile*, but that would be
better to change them with autotools (to be set at configure step). So you will
have something like @alliance_etc@ and @alliance_cells@

I think this would be better so upstream can merge thoses changes. I don't mean
to re-run autotools but to have patches to that can be merged upstream...

About the desktop files (nices icons)
Thoses links wasn't working has alliance_bin wasn't yet in the path...
(I expect that it will be after a reboot)

I ever you wanted to make comment (and comment{fr] ) in you .desktop files, you
have to follow :
http://developer.gnome.org/projects/gup/hig/2.0/desktop-integration.html#menu-item-tooltips
And specially uses verbs in the comments line...
Comment 25 Chitlesh GOORAH 2007-08-12 10:30:34 EDT
(In reply to comment #24)
> The aim is to sort arch dependant and arch-independant data.

Ok, will do
 
> But the remaining problems is about $alliance_top/{etc,cells,...}, Actually
> thoses directory are hardcoded in configure* and Makefile*, but that would 
be
> better to change them with autotools (to be set at configure step). So you 
will
> have something like @alliance_etc@ and @alliance_cells@
> 
> I think this would be better so upstream can merge thoses changes. I don't 
mean
> to re-run autotools but to have patches to that can be merged upstream...

should I do every upstream's job it as a packager?
Would you block the review, if I don't ?

> Thoses links wasn't working has alliance_bin wasn't yet in the path...
> (I expect that it will be after a reboot)
True
 
> And specially uses verbs in the comments line...

Will do. 

Comment 27 Nicolas Chauvet (kwizart) 2007-08-13 09:15:49 EDT
good!

* Works fine on installation/uninstallation (directory ownership is good)
Beware that upgrading from previous reviewing packages it might leave from
directory ownership problems (ie sprecially from the cells directory switch )

* Runtime test works


---------------------

This package ( alliance ) is APPROVED by me

---------------------

Comment 28 Chitlesh GOORAH 2007-08-13 11:16:36 EDT
New Package CVS Request
=======================
Package Name: alliance
Short Description: Alliance VLSI CAD Sytem
Owners: cgoorah@yahoo.com.au
Branches: FC-6 F-7 devel
Comment 29 Kevin Fenzi 2007-08-13 15:37:20 EDT
cvs done.
Note that the cvs template now should include your Fedora Account system name
instead of email, and that there is a 'cvsextras can all commit' item. 
Comment 30 Chitlesh GOORAH 2008-11-10 10:11:15 EST
Package Change Request
=======================
Package Name: alliance
Short Description: Alliance VLSI CAD Sytem
Owners: chitlesh
Branches: EL-5
Comment 31 Kevin Fenzi 2008-11-10 11:56:32 EST
cvs done.

Note You need to log in before you can comment on or make changes to this bug.