[gentoo-dev] Re: [gentoo-core] dev-lang/icc and dev-lang/ifc candidates for removal

[Danny van Dyk <kugelfang@gentoo.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tom,

> |>>Unless someone steps up, the intel compiler toolchain
> |>>packages dev-lang/icc (intel cc) and dev-lang/ifc (intel fortran
> |>>compiler) are prime candidates for removal from the tree; open bugs,
> |>>primary maintainer is retired, and no devs have moved in to pick up the
> |>>packages, let along touched the changeslogs in around a year.

> | In case there are no security Bugs, i'd like to ask you to leave them in
> | for the time being, I'm working on getting the latest versions (8.0/8.1)
> | of ifort (how it is now known) and icc into the tree. The only problem
> | are my time constraints atm :-/. Though I have ebuilds ready, it will
> | still take some time to remove some minor itches before I'd commit them.
> 
> Please contact me in case you need any help to test the ebuilds. I think
> these ebuilds are far too important to be deleted from the portage tree.
> These tools are crucial for my (and other people's) job.
> Also add sci-libs/mkl to this list.

(CCing gentoo-sci@l.g.o, as i guess i'll thus reach the majority of icc
dependant Gentoo users)

I'll appreciate any help I can get on that :-)

Some of my thoughts on current problems (w/o having searched bugzilla yet!)

dev-lang/icc and dev-lang/ifc
 * No support for icc/ifort in (g)cc-config.

 * Different naming schemes for distributed packages. A friend of mine
   has a l_intel_cc_pu_${PV}.tar.gz for his academic work. I got a
   l_intel_cc_p_${PV}.tar.gz from Intel's premier support... go
   figure... :-/ Is it valid to specify
      SRC_URI="|| ( file1 file2 )"
   in an ebuild ? Or can we use wildcards in SRC_URI?
 * icc depends on gcc's libstdc++, so changing your gcc version affects
   icc and can even break it.

sci-libs/mkl
 * integration in current virtual/{blas,lapack} scheme is missing (but
   in the works for app-admin/eclectic)
 * some lapack functions have uncommon naming scheme ('z' prefix where
   'd' would be expected.)
 * distributed via binary installer that has a rpm file as payload which
   can't be extracted. Up to now, i always have to run the installer
   once to obtain the rpm file.

all of the above
 * New versions need fetch restrictions turned on. This means for all
   users of the old (and free as in beer) versions some nastiness for
   the next update. Also, the old versions would be removed:
   Slotting? if yes, based on what?

icc/ifc use flags:
 * These are scary. Using a different compiler should not be achieved
   by setting a useflag, neither local nor global one.

I'd like to have some feedback on these problems :-)

Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCgPgXaVNL8NrtU6IRAmb2AJ4ryP18mNxTUcS/WdfHNi+LDYsXlwCgplGz
dUZIpvoc+FP0gLXgzaaF/aU=
=7/T2
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list