The matrox.eclass is utilizing this: SLOT="${KV}" /usr/lib/portage/bin/ebuild.sh contains this: check_KV() { if [ -z "${KV}" ]; then eerror "" eerror "Could not determine your kernel version." eerror "Make sure that you have a /usr/src/linux symlink," eerror "and that the indicated kernel has been configured." eerror "You can also simply run the following command" eerror "in the directory referenced by /usr/src/linux:" eerror " make include/linux/version.h" eerror "" die fi } So its setting SLOT="" (which means zero, nada, whatever), which is an invalid thing. Anyway, I don't see a reason why we need an eclass for a single ebuild. $ grep "inherit matrox" /usr/portage -R /usr/portage/x11-drivers/mtxdrivers-pro/mtxdrivers-pro-1.1.0_beta-r3.ebuild:inherit matrox $
How about moving the code to the single ebuild and making this eclass empty?
(In reply to comment #1) > How about moving the code to the single ebuild and making this eclass empty? Making eclasses empty breaks stuff for people with old binpkgs or installed ebuilds.
(In reply to comment #2) > Making eclasses empty breaks stuff for people with old binpkgs or installed > ebuilds. Unless there is some pkg_postrm or similar doing clean up on unmerge in the eclass, this is not true for installed ebuilds. We could even have a file that lists deprecated eclasses, having Portage touching it, to have a temporary empty file to source on unmerge. A bit different it is for binpkgs - but it's the same case as with eclasses changing and suddenly incompatible ebuilds in overlays: Up to now, there's absolutely nothing ensuring it will work after the next sync.
That's why you don't make backwards-incompatible changes to eclasses...
(In reply to comment #4) > That's why you don't make backwards-incompatible changes to eclasses... It can happen all the time for the one or the other reason. And no one cares for - or possibly even knows about issues with - ebuilds removed from the tree half a year ago. When you want to use binary packages reliably, use a static tree.
(In reply to comment #2) > Making eclasses empty breaks stuff for people with old binpkgs or installed > ebuilds. I really could care less whether this will break come obscure driver binpkg that is already broken because of kernel updates anyway. This eclass should go to /dev/null.
(In reply to comment #6) > (In reply to comment #2) > > Making eclasses empty breaks stuff for people with old binpkgs or installed > > ebuilds. > > I really could care less whether this will break come obscure driver binpkg > that is already broken because of kernel updates anyway. This eclass should go > to /dev/null. > Well I do. Every dev knows that removing eclasses is not allowed; the same for making incompatable changes. If you want to make the new ebuild not inherit the eclass then do so.
(In reply to comment #7) > Well I do. Every dev knows that removing eclasses is not allowed; the same for > making incompatable changes. If you want to make the new ebuild not inherit > the eclass then do so. If someone wants to emerge a broken binpkg, he's better off having it failed. The eclass does nothing on unmerge, so making it empty won't break anything there if someone managed to install the driver by some weird chance ages ago. Having an eclass for _one_ ebuild is plain stupid. The eclass is heavily broken: - ${KV} all over the place - the eclass (and the driver) is completely incompatible with modular X, it will just die. - doesn't use linux-mod, the kernel module install is thus broken as well - as an added bonus it creates directories in /dev in postinst, oh yay! So, may I ask why do we need this horrible thing in the tree and what kind of compatibility are you trying to maintain here?
To top this, the driver version we have an ebuild for can no longer be downloaded anywhere on Matrox website.
SLOT is set to 0 now.
