I was wondering how distribution creators dealt with this problem. It seems that the "sources" part of RPM management gets a bit confusing after a time. There isn't an "erase" or "uninstall" for source packages -- after they are distributed into the the /usr/src/packages directory, there isn't easy way to tell which sources in the "SOURCES" dir go with which package. Sure, one can go through each spec file by hand and attempt to come up with a list of sources one would remove from SOURCES, but it's not like in the "BUILD" directory where everything you need to delete regarding a package is generally in 1 directory. Would it be violating some "spec" or cause major disruptions if the SuSE distro managers/creators were to create package-specific subdirectories under SOURCES to hold the sources for the specific packages? I tend to build packages every once in a while and run into the problem of being able to "cleanup". The BUILD and SPEC directories are simple enough, but SOURCES? Ick. Another "problem", which is less of a problem is when one installs 2 SRPMS (say from suse 93 & suse 10) for the same package so one can compare changes and/or differences, etc. It would really be "useful" if, at least, the _spec_ files were named slightly differently for different major&minor versions. I.e. "Bash-3.0" would have spec bash30.spec, 3.1 -> bash31.spec. While the naming issue isn't too difficult to work around, the idea of putting each RPM's sources in a different subdirectory would be real helpful and significantly less of a security problem. It isn't unlikely that 2 different packages might have the same name for some source or patch, possibly variants on each other, or possibly nothing to do with each other. If one unpacks both, it's possible that one package might be built using the wrong source. I would agree it is an unlikely occurrence, but separate subdirectories under SOURCES would virtually eliminate possible source file name collisions between different packages. Is this doable or desirable? Linda