Noting this so I don't forget: - Every 3.x (and cvs) kdebase package installs the same /etc/pam.d/kde. It should therefore move to an independant package on which kdebase would depend. - Every 3.x kdebase (starting wth some revision) makes the $KDEDIR/share/apps/kdesktop/pics/ directory a symlink to /usr/share/pixmaps. This allows kde to see the gnome icons while installing its own as well (the gnome icons' filenames are all prefixed with 'gnome-' so there's no danger of conflicts.) However that means all the 3.x kdebases put the same files in /usr/share/pixmaps and happily overwrite one another. So this needs a separate single package too - except that different kde versions have different iconsets. Arg. These icons include the kde splash screen, so we can't mix versions here. Arg again. This needs to be looked at...
For item 1: maybe we're better off installing /etc/pam.d/kde-$ver files and telling the kdebase configure to use those files? In case in the future we might want differemnt KDEs to have different pam.d files. Is that likely to happen? For item 2: does current kde cvs change anything about that? Do freedesktop.org standards some into play? Will kde look in /usr/share/pixnaps without that symlink as well? Other kde ppl, please comment...
I think having just one pam file used by all ebuilds is maybe a better solution. In most cases having just one kde pam file is better. Users that prefer it otherwise could be served by a use flag, or by manual intervention About the artwork. If it is necessary to install in that shared dir I think it might be best to split those icons out into their own kde-icons package, and have the kde depend on a version bigger than itself. (Assuming no icons will be removed) What do the kde people themselves think about this anyway?
#1 - I agree with Paul #2 - A possible solution (though perhaps not the best): pics get installed into version based subdirs (/usr/share/pixmaps/3.0, usr/share/pixmaps/3.1, etc). At kde startup time, we softlink all pics in /3.0 (if that's the version starting) back into /usr/share/pixmaps. If later 3.1 starts, then all of those pics get softlinked back into /usr/share/pixmaps. Perhaps we also keep track of the last kde version started, so we don't redundantly have to softlink back over and over again if the same version is starting multiple times in a row.
That doesn't work for multiple users though, that use different kde versions.
I agree with Paul. Caleb's #2 solution is unusable when several different versions of KDE run at the same time. I'm for adding kdm-pam and kdesktop-pics packages. Goes along nicely with the split ebuilds ;-) Objections?
kdm, kscreensaver and kcheckpass all use pam files, and can use separate ones (set at compile time). A single file is installed by default, but since this isn't a configuration issue, perhaps we should use three separate files to allow users the greatest configurability? Also, we could make them install and use files named foo-$PV instead of having a separate kde-pam ebuild provide a single file. Very very few people would need this, but it isn't any more difficult to do for us. It does clutter pam.d somewhat.
Split ebuilds for beta1 now have a kdebase-pam package (that installs files with unversioned filenames).
I was going to switch kde-base/kdebase-3.4 to depend on kdebase-pam, too, but for this bug to be resolved, shouldn't kdebase-pam be unversioned and unslotted?
Yes, unless we want to allow people to maintain separate pam configurations for different KDE versions. I'm not really into pam, so I can't present a scenario where that'd be necessary. So I don't mind not allowing this. And we can always add it later. Yes, the current ebuild should be unversioned and unslotted. I'm changing its slot to 0 and its version number to 4 to get people to upgrade, and adding an appropriate slotmove instruction to the updates file. If that's ok with you, please use it from the kdebase ebuild.
Excellent. Do you think we can remove kdebase-pam from package.mask to use it for the next revision of kdebase-3.3.2?
OK with me.
Everything is fine now. We have kdebase-pam used by 3.3 and 3.4, and 3.4 does not use /usr/share/pixmaps anymore. Closing.
