[Bug 344884] New: static executables are missing from module-init-tools
https://bugzilla.novell.com/show_bug.cgi?id=344884 Summary: static executables are missing from module-init-tools Product: openSUSE 10.3 Version: Final Platform: i586 OS/Version: openSUSE 10.3 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: zoli@polarhome.com QAContact: qa@suse.de Found By: Customer In erlier releases there are the following static executables delivered: /sbin/insmod.static /sbin/lsmod.static /sbin/modinfo.static /sbin/modprobe.static /sbin/rmmod.static In 10.3 release Name : module-init-tools Relocations: (not relocatable) Version : 3.2.99.pre11 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany Release : 23 These static executables are missing. These static executables are extremely vital in deploying OpenSuSE based initrd's.
From other side there is not a big deal to deliver them for the rpm builder.
Thank you in advance. Regards, Z -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=344884 Mark Gordon <mtgordon@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtgordon@novell.com AssignedTo|bnc-team-screening@forge.provo.novell.com |mmarek@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=344884#c1 Michal Marek <mmarek@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |zoli@polarhome.com --- Comment #1 from Michal Marek <mmarek@novell.com> 2007-11-30 03:01:26 MST --- openSUSE's mkinitrd doesn't use the static binaries, nor does the installation or rescue system, which was the reason for dropping them (see the rpm changelog). What is your use case for the static binaries? What about a %if 0%{?_with_static_tools:1} .. build static tools %endif rebuild option? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=344884#c2 Zoltan Arpadffy <zoli@polarhome.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|zoli@polarhome.com | --- Comment #2 from Zoltan Arpadffy <zoli@polarhome.com> 2007-11-30 04:31:24 MST --- Hello,
openSUSE's mkinitrd doesn't use the static binaries
I agree with you, but have you ever think about other users that might use OpenSUSE rpm packages for other purpose. There might be a serious application behind that depends of such static executable. In particular we are using OpenSUSE as a base distribution for creating lightweight operating system for some POS terminals. We have our own installer etc, in fact just a limited number of rpm packages are used from OpenSUSE. We have chosen SuSE and later OpenSuSE because of stability, reliability, good support, well tested packages, good update mechanism etc. Unfortunately, lately there are many unpredictable changes in OpenSuSE that jeopardize the whole concept. Many small well proven features are removed and the backwards compatibility is lost. In fact all 3rd party user, like we, has tremendous problems with every new release because of such issues. In 10.3 the static executables have been removed, the kernel does not recognize minix file system and lot of other issues. If there is any chance, I would suggest to keep up with the development, new features are welcome, but always keep in mind the backwards compatibility. There might be users in the aether who might use your distribution more seriously than a desktop OS. Sure, rebuild is a solution, or use some older version of the rpm package... but is this really needed? Do harm somebody those static executables? Has the package improved with removing them? .. and yes - all users that have used them are now missing them, just because you did not need them. My opinion is that this is a bit selfish, short vision approach... this will make that serious users that maintain complicate applications based on your distro - will move away from your distribution slowly. I like OpenSuSE. It is worth fighting for. This is the reason why I raise my voice and want to turn your attention on importance of backwards compatibility issues - before it is too late. Thank you in advance. Regards, Zoltan Arpadffy System Architect/Project manager Scientific Games Sweden -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=344884#c3 --- Comment #3 from Michal Marek <mmarek@novell.com> 2007-11-30 07:38:21 MST --- (In reply to comment #2 from Zoltan Arpadffy)
Hello,
openSUSE's mkinitrd doesn't use the static binaries
I agree with you, but have you ever think about other users that might use OpenSUSE rpm packages for other purpose.
But those aren't "average" users, right? I mean, the change was made half a year before the 10.3 release and I haven't seen a single bugreport during the alpha and beta phase (hint, hint).
Sure, rebuild is a solution, or use some older version of the rpm package... but is this really needed?
You modify the distro anyway, so what's the problem with having the desired package one rpmbuild --rebuild --with static_tools module-init-tools*.src.rpm away? You can even let the Build service do this automatically with each new version of the package...
Do harm somebody those static executables? Has the package improved with removing them?
It's 2/3 of the size in 10.2. Not _that_ much of an improvement, but for the 10.3 live CDs, every kilobyte was precious.
... and yes - all users that have used them are now missing them, just because you did not need them. ^^^ ? Me and the vast majority of other users didn't and doesn't need them.
My opinion is that this is a bit selfish, short vision approach... this will make that serious users that maintain complicate applications based on your distro - will move away from your distribution slowly.
My point that it's impossible to build one-size-fits-all _binary_ packages. That's why I'm proposing a packaging that let's you easily rebuild the the package to fit your needs.
I like OpenSuSE. It is worth fighting for. This is the reason why I raise my voice and want to turn your attention on importance of backwards compatibility issues - before it is too late.
That's all fine. But the right time to raise such concerns is before the release, not after. There have been public betas since SL 10.0. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=344884#c4 --- Comment #4 from Zoltan Arpadffy <zoli@polarhome.com> 2007-11-30 11:59:43 MST --- Hello,
You modify the distro anyway, so what's the problem with having the desired package one rpmbuild ... away?
Excuse, me but I have never told that we modify the distro. We do use rpm packages built, tested, signed and delivered by SuSE. With this both we and our customers show respect and trust in SuSE's quality level and test force. By making an rpmbuild we loose the "provided by SuSE" concept.
it's impossible to build one-size-fits-all _binary_packages The only thing I as is to be backwards compatible - all the time.
Here is a trivial example - between us coders: You must have upgraded bash from 2.04 to 3.0 lately. And I guess that you have never ever thought about that some of your scripts will broke after that upgrade. Right? Or Vim 7.1 would behave differently than 6.4... right? This is what I expect with every other package including module-init-tools and kernel as well. I don't think that is somewhat unreal requirement?
But the right time to raise such concerns is before the release, not after.
Yes, I agree with you... but I could not even imagine that something like this could happen. I work with SuSE since 8.0 and it has been all the time backwards compatible. .. but lately since 10.2 it became more progressive, diffuse and compatibility ignorant. .. and as I told this is not the sole issue. What about /proc/bus/usb to /dev/bus/usb problem where the user community forced SuSE to configure kernel on the old "compatible" way? Also building ramdisk driver as module making impossible use to ext2 and minix fs initrds - it was also a wise decision :) Should we, users test every beta release just to check if you were made something incompatible? Backwards compatibility is a must - the common sense of software development. If this is bacwards ignorance is the official OpenSuSE aproach, then users should be informed about - in order to not to put to much effort in application generalization that is independent of SuSE distro version. I am sorry for bitter words. Please do not take them personal. This is a philosophical, design approach question and not a personal issue. Have a nice weekend. Regards, Z -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=344884#c5 --- Comment #5 from Michal Marek <mmarek@novell.com> 2007-12-03 09:36:48 MST --- (In reply to comment #4 from Zoltan Arpadffy)
Hello,
You modify the distro anyway, so what's the problem with having the desired package one rpmbuild ... away?
Excuse, me but I have never told that we modify the distro.
Ok, call it customize or "add custom packages to the distro".
We do use rpm packages built, tested, signed and delivered by SuSE. With this both we and our customers show respect and trust in SuSE's quality level and test force.
This is an interesting point: You want the "tested by SUSE" seal, but have you thought how much testing goes into stuff that's not used at all (within the distro and by the majority of users)? There's little value added if we build the static tools and not you.
The only thing I as is to be backwards compatible - all the time.
No way. If we had to keep every single file forever and were never allowed to modify the behavior of any program, we wouldn't move anywhere. Try reporting the other problems you mentioned to upstream developers of bash, vim, etc and you'll most likely get a similar response. You can't have the latest and greatest and at the same time be 100% backwards compatible for years. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=344884 User zoli@polarhome.com added comment https://bugzilla.novell.com/show_bug.cgi?id=344884#c6 --- Comment #6 from Zoltan Arpadffy <zoli@polarhome.com> 2007-12-03 13:59:54 MST --- (In reply to comment #5 from Michal Marek)
The only thing I as is to be backwards compatible - all the time. No way. If we had to keep every single file forever and were never allowed to modify the behavior of any program, we wouldn't move anywhere.
This is not true - see bash, Vim and many other (almost every) packages
Try reporting the other problems you mentioned to upstream developers of bash, vim, etc and you'll most likely get a similar response. You can't have the latest and greatest and at the same time be 100% backwards compatible for years.
I am one of the upstream developer of Vim. This is the reason why I am absolutely positive that Vim has added features but has not removed or produced incompatibility during past ten year - while I was involved. Also if you would read one more time my comment regarding bash and Vim with higher attention, probably you would get the point what I wanted to express there. The main problem is that you (I mean SuSE and not you personally) think that you produce a final end-product - The OpenSusE Linux. Yes it might be your product that you deliver... but... ..I inform you, that your product is not an end-product but a tool, a platform for other useful applications. This is the way how the users, the community sees it. Nobody uses any Linux distro just to have it installed on a computer, but to run applications both provided by SuSE or 3rd party. Operating system, the platforms purpose is to serve this application that produces added value. .and if you (mean SuSE) can not see the importance of keeping backwards compatibility in order to serve those applications - I do not have anything more to add. You may close this ticket. Regards, Zoltan Arpadffy System Architect/Project manager Scientific Games Sweden (the guy who has spent more than 10 years in open source development, owns and runs one of the largest free shell development site in the World and today delivers tens of thousands POS-point of sales lottery terminal platforms worldwide based on OpenSuSE) - in one word I know what I am talking about - if you could not, until now, read out of my words :( -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=344884 User mmarek@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=344884#c7 Michal Marek <mmarek@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #7 from Michal Marek <mmarek@novell.com> 2007-12-04 03:13:46 MST --- (In reply to comment #6 from Zoltan Arpadffy)
(In reply to comment #5 from Michal Marek)
Try reporting the other problems you mentioned to upstream developers of bash, vim, etc and you'll most likely get a similar response. You can't have the latest and greatest and at the same time be 100% backwards compatible for years.
I am one of the upstream developer of Vim. This is the reason why I am absolutely positive that Vim has added features but has not removed or produced incompatibility during past ten year - while I was involved.
Ok, please accept my apologies for my comment about Vim, I use it daily and I must admit that I don't remember having to update my config due to incompatibilities. But I don't agree with you that new bash version has allways been 100% backward compatible, it did change and eg. configure scripts that relied on "bugs" in older versions suddenly failed. Same for make, autotools, not to mention gcc. That's why I'm skeptical about backwards compatibility being a must, Vim seems rather an exception than a rule. But back to the original topic: I don't want to reintroduce the static tools to the binary package (it's unneeded by most users, adds bloat to the Live CD, we would have to resurrect the dropped dietzlib package, and there'd be indeed no testing done), but I can change the spec to optinally build them. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com