...packages/SOURCES: getting full?; prod588.spec vs prod.spec; security concerns
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
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 ========== Linda, I think, if you learned to use your Linux setup a bit better or as you learn, you'll find all these questions not to be the problems you make
On Thursday 23 March 2006 19:45, Linda Walsh wrote: them out to be. All source packages are labeled with the name of the package, so I don't understand how they can be difficult to determine which goes with what. There is no need to further complicate things with extra directories as you suggest, one just needs to understand where things are located and deal with those. If you want to compare src.rpms, I suggest you use something like Krusader or Midnight Commander to break the rpms down to view those things you want without installing them. They are both file managers with enormous capabilities. MC is run from the shell and Krusader is on your SuSE 10 dvd ready to install. I also suggest that after each build or compile you do when moving the rpm files to another location that you also clean up your src.rpm directories as well. Again, that can be done with a root Konq or using the shell, really very simple. It really sounds like it's just a matter of you getting to know your system better. Unlike Windows, you'll find many ways to do something, some easy, some not so easy, but always doable. regards, Lee
BandiPat wrote:
========== Linda, I think, if you learned to use your Linux setup a bit better or as you learn, you'll find all these questions not to be the problems you make them out to be.
*smile* Thanks BandiPat, but I think I know how to use Linux a bit too well, being the more likely problem.
All source packages are labeled with the name of the package,
I see source names like "README", info, License, etc. Those are fairly generic names. If I install more than one source package at a time, I would think the "README" of one package would overwrite a "README" in another source directory. All I'm suggesting is "symmetry". When soures are built, they are unpacked into uniquely packaged directory names under BUILD. When they are packaged, they are built in a package-unique name under "/var/tmp" When they are stored in the binary and source directories, all files are packaged into 1 uniquely named file. Since every part of the BUILD uses separately named directories, why not store sources in separately named directories as well? Source file names can conflict. In 9.3, there are 265 filenames that are identically named that are in 2 or more packages. The winner in 9.3 is "README.SuSE" with 80 source packages having that file. If one unpacks more than one version at a time -- which, if you are familiar with kernel building in "/usr/src", is quite common, it would be easy for a built package to pick up the README.SuSE of the wrong source package.
If you want to compare src.rpms, I suggest you use something like Krusader or Midnight Commander to break the rpms down to view those things you want without installing them.
I prefer to use the shell. I tried Midnight Commander, once. It was far too easy to trigger the wrong key and have it delete a directory of files. Just another non-unix utility to use to confuse things. I prefer diff, vi, mostly shell tools.
I also suggest that after each build or compile you do when moving the rpm files to another location that you also clean up your src.rpm directories as well. Again, that can be done with a root Konq or using the shell, really very simple.
---- Well, that's the problem. I prefer to have more than one source unwrapped at one time. Different people have different ways of doing things. I thought using different subdirectories for sources would be just a smart as using different subdirectories for BUILD. Can you give me a good technical reason why they should be inconsistent?
It really sounds like it's just a matter of you getting to know your system better. Unlike Windows, you'll find many ways to do something, some easy, some not so easy, but always doable.
I thought it was in Windows that ways to do things were "fixed" (set) in stone by MS. I had the impression Linux was more flexible. That's why I suggested a _different_ way of doing something in Linux. The problem of non-unique source file names gets worse in suse 10.0. As I mention in the subject if someone unpacks more than one source file, the chances of building an RPM with the same-named file from another package increases. When RPM's are built -- they take care to build in a clean environment. That is handled by the build tool RPM. It deletes the old build directory first to ensure there won't be a confusion between the old build and a new build. If it was intended only to unpack 1 source package at a time, I assert that the RPM tool would be smart enough to delete everything under /usr/src/SOURCES, before unpacking a source RPM. If the RPM developers were smart enough to delete conflicting directories under BUILD, don't you think that they would have done it under SOURCES if was intended that only 1 package be unpacked at a time? If I unpack sources under /usr/src/SOURCES, (assuming no name conflicts), I can easily build more than one RPM at the same time -- as they all build in separate build areas. Why would the makers of RPM deliberately break the ability to do parallel building of RPMs? Separately named directories under SOURCES would help ensure a non-overlap of source file names. -linda
regards, Lee
On Monday 03 April 2006 22:44, Linda Walsh wrote:
BandiPat wrote:
========== Linda, I think, if you learned to use your Linux setup a bit better or as you learn, you'll find all these questions not to be the problems you make them out to be.
--- *smile* Thanks BandiPat, but I think I know how to use Linux a bit too well, being the more likely problem.
All source packages are labeled with the name of the package,
--- I see source names like "README", info, License, etc. Those are fairly generic names. If I install more than one source package at a time, I would think the "README" of one package would overwrite a "README" in another source directory.
No, you *don't* seem to "know how to use Linux a bit too well", according to the above statement. <snip rest of your inanities>
On Thu, 23 Mar 2006 16:45:45 -0800, Linda Walsh wrote:
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?
It would cause major disruption as that change would have to be done inside the rpm utility and SUSE is not going to deviate here from the standard rpm.
I tend to build packages every once in a while and run into the problem of being able to "cleanup".
I do too, but only one package at a time and then I save away the newly created source and binary packages, clean up BUILD, SOURCES and SPECS and uninstall the old .src.rpm.
I.e. "Bash-3.0" would have spec bash30.spec, 3.1 -> bash31.spec.
That's nothing SUSE is going to force and so it's not going to happen.
the idea of putting each RPM's sources in a different subdirectory would be real helpful
I guess you're rather alone there as I've not seen others complain.
and significantly less of a security problem.
AFAICS, there is no security problem! So please tell me where you think one exists.
It isn't unlikely that 2 different packages might have the same name for some source
Wrong! It's *very* unlikely for 2 different packages having the same name.
or patch,
Yes, that's much more possible, but that's why most patches nowadays *have* the name of the package prepended.
Is this doable or desirable?
No, but nobody is going to keep you from moving sources to their own subdirectory. And if you start using the package build, you'll not have to worry about those things either. BTW, it would be *much* more preferable that you discuss things like this on the opensuse mailing list as these things will not be changed in existing distributions. Philipp
Philipp Thomas wrote:
It would cause major disruption as that change would have to be done inside the rpm utility and SUSE is not going to deviate here from the standard rpm.
I guess you're rather alone there as I've not seen others complain. I'm usually one of the first to see potential conflicts that could result in unnecessary headaches or security problems, but
--- How would it cause any disruption? Let alone, major? then that's just my curse.
and significantly less of a security problem.
AFAICS, there is no security problem! So please tell me where you think one exists.
It isn't unlikely that 2 different packages might have the same name for some source
Wrong! It's *very* unlikely for 2 different packages having the same name.
---- Here is where we differ. In SuSE 9.3, I count 265 different names that are duplicated in two or more packages. All told, 503 duplicate names. In SuSE 10.0, that figure goes up: 430 unique names that are duplicated, 969 duplications. That many occurrences fits my definition of "not unlikely". Unlikely != impossible. All you need is 1 duplicate source filename with different contents in two different packages that are built at the same time on the same machine and you will end up with the wrong contents in one of the packages. If you are lucky, the impact will be zero, if you are unlucky, the patch will patch in code that compiles but has latent bugs waiting to be exposed. At the very least, though, you end up with RPMs built from wrong sources. It's a potential security concern, waiting to happen. If it is required to only unpackage the sources for 1 RPM at a time, then RPM should clean out the SOURCES directory before unpacking new sources into it, but this would prevent parallel RPM builds would it not? It seems common to build more than one RPM at a time on a multi-cpu machine. Not using separate subdirs for SOURCES would be only slightly more safe than not using separate subdirs in the BUILD directory.
Yes, that's much more possible, but that's why most patches nowadays *have* the name of the package prepended.
--- Some do, some don't. There is no enforcement or standard. Try this (bash shell): (for i in <sourcedir>/*.src.rpm; do rpm -qlp "$i" done) >allsources.txt That should dump about 15,000+ source file names into allsources.txt. From there you can use "sort" into "uniq -dc" and you'll see plenty of source-filename duplications. You also will not be able to tell which source rpm most of the names come from. If there is no parallelism in distribution builds, this may not be an issue for those builds, but for anyone unwrapping, looking at, and/or building more than one RPM at a time on the same machine, it's a potential pitfall. -linda walsh
On Monday 03 April 2006 23:22, Linda Walsh wrote:
Philipp Thomas wrote:
It would cause major disruption as that change would have to be done inside the rpm utility and SUSE is not going to deviate here from the standard rpm.
--- How would it cause any disruption? Let alone, major?
I guess you're rather alone there as I've not seen others complain.
I'm usually one of the first to see potential conflicts that could result in unnecessary headaches or security problems, but then that's just my curse.
And your "curse" *only*. Things seem to work just fine for everyone else (though you seem to think yourself to be 'better' than everyone else). If you don't like things the way they are, do yourself and this list a favor and make yourself an LFS system. <snip rest of your inanities>
* Linda Walsh (suse@tlinx.org) [20060404 06:22]:
How would it cause any disruption? Let alone, major?
It would be a major deviation from the way rpm works and Novell/SUSE is not going to do something like that all alone. Again, you've picked the wrong list to discuss a topic. The right address for something like this would be rpm-devel@lists.dulug.duke.edu.
In SuSE 9.3, I count 265 different names that are duplicated in two or more packages. All told, 503 duplicate names.
Inside a .src.rpm? A normal .src.rpm contains one or more tarballs, a .spec .file, a changes file and varying numbers of patches.
If there is no parallelism in distribution builds, this may not be an issue for those builds, but for anyone unwrapping, looking at, and/or building more than one RPM at a time on the same machine, it's a potential pitfall.
Then do it differently! For instance don't install the .src.rpm but rather unpack it where you like and write a script that cleans /usr/src/packages/SOURCES and then copies your sources there. That's the way the build script basically works (it also sets up a chroot environment to build the packages in). Philipp
participants (5)
-
BandiPat -
JB -
Linda Walsh -
Philipp Thomas -
Philipp Thomas