Re: [Cooker] Cooker Compile
edward == Edward Avis [EMAIL PROTECTED] writes:
Hi
This is a nono, if you need glibc-devel, ask for it. Notice than
asking for make don't make too many sense, as rpm should depend on
it.
edward Why should rpm depend on make? I'm not aware that rpm ever calls make
edward for anything - unless the spec file asks for it, but of course the spec
edward file could ask for anything at all.
sorry, not rpm, rpm-devel.
[greping sources]
I was wrong, /usr/lib/rpm/*/macros belong to rpm instead of rpm-devel
quintela$ rpm -qf /usr/lib/rpm/i586-mandrake-linux/macros
rpm-4.0.3-0.13mdk
quintela$ grep make /usr/lib/rpm/i586-mandrake-linux/macros
# XXX I'll make these the default linux values soon as I can.
# make
%_make_bin make
%make if [ -z $NPROCS -a -f /proc/stat ]; then NPROCS=`egrep -c ^cpu[0-9]+
/proc/stat || :`; fi; if [ -z $NPROCS -o $NPROCS -le 0 ]; then NPROCS=1; fi;
%{_make_bin} -j$NPROCS
%make_session if [ -x %{_fndsession_bin} ]; then %{_fndsession_bin} ||
true ; fi
you can see that rpm has embodied calls to make, but you are right, it
don't depend on it (and shouldn't, I think that rpm-devel should, but
that is a different story).
edward Shouldn't it be possible to install a small system without make? RPM is
edward essential to Linux-Mandrake, if you make rpm depend on make, then you
edward have made make essential too. But that doesn't reflect reality AFAIK.
I agree here, rpm should work without make, rpm-devel (or whatever
will be its name, not).
- Mandrake install gcc make in a default install, but:
1- that can change (a end user don't need make normally).
2- you don't want to have installed gcc/make whateven in one
firewall and similar devices.
edward So why make rpm depend on make? Or have I misunderstood you?
sorry for the confusion :(
Where do you draw the line, easy, if the package is in basesystem, you
don't need to ask for it, otherwise you need to ask for it explicitly.
edward Okay, and there is a stated assumption that if you don't have the
edward default base system installed, you can't expect to build packages?
I think that this is not an assumption, it is that if you remove _any_
package for basesystem, the system _could_ not work properly. It is
called basesystem for something :)
edward Again, I would suggest a package called 'base-system' which depends on
edward all the stuff included in the standard install. Then uninstalling gcc,
edward for example, would warn that you were losing base system functionality
edward (in an obscure kind of way) and you'd have to explicitly ask for this.
no, basesystem is _way_ less than standard install, it is the
_minimun_ ammount of packages to make the system work. You can think
of it as similar to minimal install allowed.
edward Similarly trying to build an RPM would warn that you need base-system
edward installed, and you couldn't install the base-system package without
edward actually having the needed stuff.
Sure, see above, if you remove _anything_ of basesystem:
1- it is better that you know what are you doing
2- nothing is guaranteed to work after that
edward However I think you would also dislike that idea. One could argue that
edward if you go around removing basic packages like make, you probably know
edward what you're doing and you can expect to take the consequences. Newbies
edward or moderately experienced users wouldn't do that. I think this is a
edward sensible position. But you still need to define what the base system
edward is, and wouldn't it be best for the user to get some warning that he is
edward about to uninstall base system functionality?
No, remove make is ok, and shouldn't be in the base-system. Having
rpm-build, or rpm-devel depending of make look right to me.
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
Re: [Cooker] Cooker Compile
Juan Quintela wrote: No, remove make is ok, and shouldn't be in the base-system. Having rpm-build, or rpm-devel depending of make look right to me. Yes, I think that rpm-devel should need every package that a macro refers to, this includes autoconf, make, and gpg, amoung others. Perhaps I should go through and make a list? -- Sincerely, David Walluck [EMAIL PROTECTED]
Re: [Cooker] Cooker Compile
edward == Edward Avis [EMAIL PROTECTED] writes: edward On Sat, 7 Jul 2001, Stefan van der Eijk wrote: And how about a package 'essential-devel' which depends on gcc, make and all the other devel stuff included in a Mandrake default install. This package wouldn't contain any files, it would just act as a convenient collection of dependencies, so that if essential-devel is installed you know the basic stuff is there. Then you'll need to install one package that Provides: essential-devel. edward Yes. It would probably be installed as part of a standard Mandrake edward setup - unless MandrakeSoft decide to drop gcc and make from the edward standard install. This is a nono, if you need glibc-devel, ask for it. Notice than asking for make don't make too many sense, as rpm should depend on it. That means that: - you have make autoconf implicit dependencies from rpm inherited for each package. - You need to ask for the rest. - Mandrake install gcc make in a default install, but: 1- that can change (a end user don't need make normally). 2- you don't want to have installed gcc/make whateven in one firewall and similar devices. edward Agreed. The question is, do we want to list *every single package* as a edward BuildRequires line? Surely we can't have a hundred lines listing edward dependencies on bash, textutils, gzip, and so on. So where do you edward draw the line, and having done so is there an easy way to make sure that edward these prerequisites are installed? (Nobody could uninstall bash, but edward it's possible to imagine a basic Mandrake install without, say, edward glibc-devel.) bash is also an implicit dependency of rpm. Where do you draw the line, easy, if the package is in basesystem, you don't need to ask for it, otherwise you need to ask for it explicitly. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy
Re: [Cooker] Cooker Compile
david == David Walluck [EMAIL PROTECTED] writes: Hi david The idea would be that you only needed basic compiler et. al, anything david that was downloaded as a binary, for example gcc, would be compiled at the david final stage of the install, after all the other packages were built david successfully. Again, without an optimized compiler, you may also fail to david get optimized packages, but as I have said in pervious e-mails, lots of david packages have problems with some optimizations thata re supposedly safe, david meaning they will fail to compile. So the question becomes, if only the david optflags that were originally used are safe, what benefits do we get from david recompiling? In my case I wonder if -march=athlon -O2 is even faster than david -O3 -march=pentiumpro. Again, in some cases we are talking a 'mere' 5% david increase, but I have always thought one of the main advantages to having david the source code was so that you could make the most from your hardware. Notice that for the majority of the packages, it doesn't matter if it has been compiled optimized or not, only glibc, gcc (if you are a developer), kernel and a few other packages are really important. It is really the same if your xbiff/xclock whatever takes 0.01 ms or 0.1 ms, it is a 10x improvement (which I think that is very difficult to achieve) and you will not we seeing the difference. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy
Re: [Cooker] Cooker Compile
Edward Avis wrote: So why make rpm depend on make? Or have I misunderstood you? Okay, and there is a stated assumption that if you don't have the default base system installed, you can't expect to build packages? Maybe a basesystem-devel? There are many programs used internally by rpm scripts for example that aren't listed as Required. This of perl, awk, and sed, cpio. And then all C programs need autoconf, automake, libtool, glibc-devel, gcc, make, and probably several I have missed. Nowhere are these programs even implicitly required for building an RPM though 99 times out of 100 they are needed. -- Sincerely, David Walluck [EMAIL PROTECTED]
Re: [Cooker] Cooker Compile
So sprach David Walluck am Sun, Jul 08, 2001 at 01:56:18AM -0400: If I have libfoo1 on my system, and now libfoo2 is needed in say Mandrake 8.1, I no longer need libfoo1. I am wishing for a script that would go through and remove packages which no longer have dependencies. Something like urpmi, but backwards. I usee rpme, but this seems to be as useful as rpm -e or less :) Something like urpmi_rpm-find-leaves ? But doing a urpme $(urpmi_rpm-find-leaves) is probably a BAD idea, as it not onle removes stale libraries (like libfoo1), but also about all the applications... But I don't see how this can be solved, as a stale lib cannot be distiguished from a normal app. Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 1 day 15 hours 6 minutes
Re: [Cooker] Cooker Compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 7 Jul 2001, Stefan van der Eijk wrote: And how about a package 'essential-devel' which depends on gcc, make and all the other devel stuff included in a Mandrake default install. This package wouldn't contain any files, it would just act as a convenient collection of dependencies, so that if essential-devel is installed you know the basic stuff is there. Then you'll need to install one package that Provides: essential-devel. Yes. It would probably be installed as part of a standard Mandrake setup - unless MandrakeSoft decide to drop gcc and make from the standard install. I'm not sure if this is the way to go, it's got an artificial feeling... I think it is the least messy option. I don't know if there is precedent for this sort of thing though. The result of the BR march should be that no matter which package you're going to rebuild, if you install the BuildRequires, a (hopefully) good package is going to come out. Agreed. The question is, do we want to list *every single package* as a BuildRequires line? Surely we can't have a hundred lines listing dependencies on bash, textutils, gzip, and so on. So where do you draw the line, and having done so is there an easy way to make sure that these prerequisites are installed? (Nobody could uninstall bash, but it's possible to imagine a basic Mandrake install without, say, glibc-devel.) - -- Ed Avis [EMAIL PROTECTED] Finger for PGP key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7SDNHIMp73jhGogoRAqHiAJwIW9bJLQKpRIAbIuOSHFx9ks6ppwCfaxN4 iiseknjD0aVj9nNeh29W6wY= =QD8K -END PGP SIGNATURE-
RE: [Cooker] Cooker Compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jul 2001, David Walluck wrote: The Mandrake Install program... I mean could you recompile the SRPMS, but them in a directory on a separate HD, boot with the mandrake HD bootfloppy image, and use them to install Mandrake? Certainly if they are named i586... I don't know at the moment how to make it look for i686, athlon, etc, but hopfully it's as easy as changing one line in a config file somewhere. Ideally the installer would look around for the most appropriate directory to use. For example: 'Hmm, I see this machine has an i686 processor. Look for an i686/ directory - nope. The next best choice for this processor is i586/ - yes, use that.' This check could be done on a per-package basis rather than once at the start of the install. Then Mandrakesoft could distribute a CD with mostly i586 packages but also i686 versions of a few selected things like the kernel and the GIMP. It would be nice to be able to build optimized packages for your particular processor, place them inside the install tree, and have them Just Work without needing to modify the installer. Maybe the Mandrake installer already does this? - -- Ed Avis [EMAIL PROTECTED] Finger for PGP key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7SDZlIMp73jhGogoRAmCxAJ4y5PH6f0Lb2yTF7S+DXGPGaHuhdwCeL910 yr1jpvURAWui2GR0jt1heGA= =boVc -END PGP SIGNATURE-
Re: [Cooker] Cooker Compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jul 2001, David Walluck wrote: But, the main problem is that the BuildRequires aren't accurate at the moment in cooker. Without the correct BuilRequires you're going to encounter many compile problems. I am worried because I have done a full install of all packages at one point and still get many compile errors. I wonder how the package maintainers built the packages in the first place... certainly not in a true 8.0 environment. You could adopt the principle that all packages in Cooker should be buildable from 'true 8.0', or whatever the last stable Linux-Mandrake release was. But I think that is too limiting. A new package might need the new version of some libraries too. Better to say that it should be possible to build Cooker packages by installing a few selected dependencies. So if the foozip compressor needs a newer version of libfoo, you can first get libfoo from Cooker, build, compile and install it on 8.0, and then have a system ready to build Cooker's foozip package. Of course libfoo itself may have build dependencies that require grabbing packages from Cooker - but eventually it should be possible to start from 8.0. In practice, I have never found that this is not the case. You can indeed build Cooker stuff on 8.0, if you're prepared to upgrade a few dependencies first. But the job is made harder by the lack of BuildRequires lines. Hopefully, making sure the BuildRequires lines are correct will make it easier to selectively build and install Cooker packages, as well as helping people build standard 8.0 packages from source. - -- Ed Avis [EMAIL PROTECTED] Finger for PGP key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7SDfGIMp73jhGogoRAkh2AJ4pCGmvb+XhZ+3OQ1m6z+KEbCPHbQCfez4j KiPQqUIL/nyqFjwyhbxbW7A= =hw5m -END PGP SIGNATURE-
Re: [Cooker] Cooker Compile
edward == Edward Avis [EMAIL PROTECTED] writes: Hi edward To be really slick: if a package fails, your script could randomly edward install some extra packages on the machine (perhaps 50% at random of the edward total packages in Cooker) and try again to build. If that succeeds, edward remove some packages and try again, etc. By a kind of binary search you edward would find the minimal set of packages needed, and those could be added edward to the spec files as BuildRequires lines. Instead of that, it is easier, to convince the script to search through .h and .c files for #include and search what -devel packages provide that. edward Once all the dependencies are correct, it wouldn't take long to just edward verify that things work whenever a new package is released, just as a edward kind of sanity check. It might be good for Mandrakesoft to dedicate a edward fairly old, slow box to doing this 24 hours a day - getting the latest edward uploads to Cooker, uninstalling everything except essential packages and edward what's mentioned in BuildRequires, trying to build it, sending mail to edward the maintainer if it fails. Compiling the kernel in one Athlon 1200Mhz with 512MB of RAM (i.e. everything is in RAM, the disk that you have doesn't matter) takes more than 1 hour. Any old machine will not support that very well :( But yes, that is a good idea, just not an slow machine. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy
Re: [Cooker] Cooker Compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jul 2001, David Walluck wrote: This is really a flaw in the GNU configure mechanism. It would be nice if autoconf's configure scripts allowed you to say: % ./configure --definitely-use-libtiff First of all, it is not a problem with rpm %configure, but a potential problem with configure.in scripts. When I write autoconf scripts, I always AC_MSG_ERROR on a missing package, some people just AC_MSG_WARN, others just assume you don't want it to be supported if this feature is optional. But we can't expect the package authors to change their configure scripts just for Mandrake. To take XEmacs for an example, the configure script will leave out PNG and TIFF support if the libraries are not there. This is a useful feature if you just want to get the package built on your AIX, Solaris or Windows box, and I don't think the XEmacs developers would want to annoy their users by changing to AC_MSG_ERROR. But such behaviour is not a good idea for building RPMs, as we've discussed. So should the RPM packager change the configure script to AC_MSG_ERROR? Should we distribute a patch file for configure.in as part of the source package? I think that is too cumbersome. It would be better if configure had an option at run time to change all AC_MSG_WARNs to AC_MSG_ERRORs, apart from any that you explicitly say to not worry about. - -- Ed Avis [EMAIL PROTECTED] Finger for PGP key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7SDlSIMp73jhGogoRAiBlAJkBTzwxm3iEkSkSU/EriderdTBf4ACeOys2 +M9zp42V4OZAVBcspD1lLM0= =05mY -END PGP SIGNATURE-
Re: [Cooker] Cooker Compile
So sprach Edward Avis am Sun, Jul 08, 2001 at 11:30:58AM +0100: Ideally the installer would look around for the most appropriate directory to use. How much of a performance boost does compiling for a specific platform give anyway? In normal applications (ie. Nautilus, Evolution, KDE, Gnome, postfix, squid ), is there really a noticeable gain at all? Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 1 day 17 hours 6 minutes
Re: [Cooker] Cooker Compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jul 2001, Alexander Skwar wrote: If I have libfoo1 on my system, and now libfoo2 is needed in say Mandrake 8.1, I no longer need libfoo1. I am wishing for a script that would go through and remove packages which no longer have dependencies. Something like urpmi_rpm-find-leaves ? But doing a urpme $(urpmi_rpm-find-leaves) is probably a BAD idea, as it not onle removes stale libraries (like libfoo1), but also about all the applications... But I don't see how this can be solved, as a stale lib cannot be distiguished from a normal app. Well, you can guess... an application package has executable files, a library has no executables but does have lots of .so and .a files. - -- Ed Avis [EMAIL PROTECTED] Finger for PGP key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7SDpOIMp73jhGogoRAg/XAJ0UhdPtwk9/+clE7+v5DiZ3Zu5opQCdGBrr 7a3SH8lowTBpUgwqjcpU4Yw= =+PFt -END PGP SIGNATURE-
Re: [Cooker] Cooker Compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jul 2001, David Walluck wrote: [finding BuildRequires lines for source packages] One thing that would help, as I've detailed earlier, is to normalize the BuildRequires. Even still, sometimes I search on romfind.net when a package complains of a depdency that doesn't seem to exist anywhere in cooker. Then once I find what package it is, installing it will usually fix any depdency problems. Finding the missing dependency is the key of course. Brute force won't really help that. The method I proposed would find the missing dependency, because it would try *all* the packages. Every single one. It would be rather slow, and it would grind your hard disk rather a lot, but it would find the necessary set of packages in the end. Of course doing this by hand is not fun. That's why it's best to automate it. Even if the algorithm used is rather stupid compared to a human (who can usually make intelligent guesses about what's needed), it is a lot less work to just leave it running for a few hours and come back to look at the results. - -- Ed Avis [EMAIL PROTECTED] Finger for PGP key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7SDoMIMp73jhGogoRAnNUAJ9SMKoNUlOD8CR22K2GtmP5/pgmWACeMu5j g8l3uyioXlW/0qXHLniMlSk= =CM9J -END PGP SIGNATURE-
Re: [Cooker] Cooker Compile
Certainly if they are named i586... I don't know at the moment how to make it look for i686, athlon, etc, but hopfully it's as easy as changing one line in a config file somewhere. Just some settings with rpm... Stefan
Re: [Cooker] Cooker Compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7 Jul 2001, Juan Quintela wrote: [I proposed a way of checking dependencies by brute force, with a kind of binary search of randomly installing and uninstalling packages.] Instead of that, it is easier, to convince the script to search through .h and .c files for #include and search what -devel packages provide that. That's another useful optimization. Guess at what the dependencies might be, and try installing those. But it cannot be infallible (eg, you'd also have to grep through the configure scripts for -lwhatever lines and probably other stuff). So the brute force 'uninstall half the packages and see whether it still works' would still be needed as a fallback. - -- Ed Avis [EMAIL PROTECTED] Finger for PGP key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7SDuAIMp73jhGogoRAqxSAJ99UWmmuRgO3HR5Wq3fhBLuthGd9gCeMdNJ ISHUqzW2d4eXhbj2WNuurdo= =MG/3 -END PGP SIGNATURE-
Re: [Cooker] Cooker Compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jul 2001, Alexander Skwar wrote: [i586/ vs i686/ etc...] Ideally the installer would look around for the most appropriate directory to use. How much of a performance boost does compiling for a specific platform give anyway? Probably not as much as the hype suggests. But I think it is noticeable (5% to 10% is the figure touted for Pentium optimized gcc versus i386 gcc). In some cases you can use special instructions (MMX, SIMD, etc.) to get big speed improvements for specialized applications (image processing, SETI@Home). But in those cases the standard i386 build might contain all the possible assembler-optimized routines for different i386-compatible processors and choose between them at run time. Personally, I am thinking about rebuilding the Mandrake packages for 386 and 486 processors, so I'd like the installer to cope with that. - -- Ed Avis [EMAIL PROTECTED] Finger for PGP key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7SDxdIMp73jhGogoRAkVkAJ9cWV+hysaAqVg1/QjooTHd/f3pWQCfRDTx 4p3Y1Bg4o5YfYDx/PtLDFiM= =WZDy -END PGP SIGNATURE-
Re: [Cooker] Cooker Compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jul 2001, Stefan van der Eijk wrote: I've just uploaded my script install instructions to the list, perhaps you can modify the script to include the automatic dependancy resolving feature. It's a bash script (I'm a no-no with perl), so it should be EZ to adjust Sorry, but I think that if I implemented this algorithm it would definitely be in Perl or in some other high-level language. It's just too hairy to do it using a shell script. So I think we will have to be separate - you don't know Perl and I'm not a good enough shell programmer. Unfortunately my current job doesn't allow much time for writing scripts to fiddle with system setup; later this year when I go back to being a student I'll be able to have a go at implementing this. - -- Ed Avis [EMAIL PROTECTED] Finger for PGP key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7SELjIMp73jhGogoRAuV9AJ9g6clWYl5/+gN+rOwU18cfgIZ1DwCfVmy7 AdDie1FVN2KkmNhbcL+twRI= =+cZS -END PGP SIGNATURE-
Re: [Cooker] Cooker Compile
stefan == Stefan van der Eijk [EMAIL PROTECTED] writes: Hi This is really a flaw in the GNU configure mechanism. It would be nice if autoconf's configure scripts allowed you to say: % ./configure --definitely-use-libtiff stefan Then the developer would need to put that in the .spec file -- %configure stefan --definitely-use-libtiff I think that Ed means that autoconf try to workaround when you don't have libX to build without X functionality. That is good except when you want it to die if X don't exist, and there is nothing similar to: %configure --strict i.e. never do workarounds, if something fails (i.e. library don't exist, whatever) give a error message and abort. Note that the idea under autoconf was to make the system flexible, not to manage dependencies. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy
Re: [Cooker] Cooker Compile
edward == Edward Avis [EMAIL PROTECTED] writes: Hi edward But we can't expect the package authors to change their configure edward scripts just for Mandrake. To take XEmacs for an example, the configure edward script will leave out PNG and TIFF support if the libraries are not edward there. This is a useful feature if you just want to get the package edward built on your AIX, Solaris or Windows box, and I don't think the XEmacs edward developers would want to annoy their users by changing to AC_MSG_ERROR. edward But such behaviour is not a good idea for building RPMs, as we've edward discussed. So should the RPM packager change the configure script to edward AC_MSG_ERROR? Should we distribute a patch file for configure.in as edward part of the source package? Nope, we want to change autoconf, to get an option telling it: %configure --ac-msg-warn-means--ac-msg-error and that should be all, we are expected to create the %configure script from the configure.in script anyway. If I find a free moment, will try to implement that thing, problems are: - lack of time :( - no idea about autoconf internals - no idea about m4 :( Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy
Re: [Cooker] Cooker Compile
In 8 Jul 2001, Juan Quintela cum veritate scripsit : [...] Nope, we want to change autoconf, to get an option telling it: %configure --ac-msg-warn-means--ac-msg-error and that should be all, we are expected to create the %configure script from the configure.in script anyway. [...] (er... didn't follow this thread exactly but...) In some auto-conf'ed packages I find an option something like --treat-warnings-as-errors or --enable-warnings_as_errors (e.g. in mjpegtools). Is it this you're talking about? Frank -- Sending unsolicited commercial email to this address may be a violation of the Washington State Consumer Protection Act, chapter 19.86 RCW. Frank Meurer [EMAIL PROTECTED], PGP ID: 0x5E756DA8 Key fingerprint = 169A 1138 8DB4 528F 2F01 20A6 EDD8 49C3 5E75 6DA8
Re: [Cooker] Cooker Compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8 Jul 2001, Juan Quintela wrote: Nope, we want to change autoconf, to get an option telling it: %configure --ac-msg-warn-means--ac-msg-error Yes, that's what I meant! If I find a free moment, will try to implement that thing, problems are: - lack of time :( - no idea about autoconf internals - no idea about m4 :( I am in exactly the same position on all three points. Maybe you should contact the autoconf maintainer first to find out whether such a change would be accepted. In the short term a new version of autoconf won't come out for a while - and when it did, you'd still have to wait for the package authors to re-generate their configure scripts (or have the RPM build process do a 'make maintainer-clean' and regenerate them itself). - -- Ed Avis [EMAIL PROTECTED] Finger for PGP key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7SFmvIMp73jhGogoRAv9YAJ0eQ8Qwnku2fSx1VuzwlDsNh/01ZQCfSIco S+SCOpBtz0IA0zQOBGSp1YQ= =jO9Y -END PGP SIGNATURE-
Re: [Cooker] Cooker Compile
On Sun, 8 Jul 2001, Alexander Skwar wrote: So sprach David Walluck am Sun, Jul 08, 2001 at 01:56:18AM -0400: Something like urpmi_rpm-find-leaves ? But doing a urpme $(urpmi_rpm-find-leaves) is probably a BAD idea, as it not onle removes stale libraries (like libfoo1), but also about all the applications... But I don't see how this can be solved, as a stale lib cannot be distiguished from a normal app. Well, now they can, by either the addition of an extra rpm tag, or simply by the naming convention that all libs should start with the 'lib' prefix. Of course libfoo1 also has a correspinding foo1 package that would probably need to be uninstalled too. -- Sincerely, David Walluck [EMAIL PROTECTED]
Re: [Cooker] Cooker Compile
On Sun, 8 Jul 2001, Frank Meurer wrote: In 8 Jul 2001, Juan Quintela cum veritate scripsit : [...] Nope, we want to change autoconf, to get an option telling it: %configure --ac-msg-warn-means--ac-msg-error and that should be all, we are expected to create the %configure script from the configure.in script anyway. [...] (er... didn't follow this thread exactly but...) In some auto-conf'ed packages I find an option something like --treat-warnings-as-errors or --enable-warnings_as_errors (e.g. in mjpegtools). Is it this you're talking about? Frank Hmm, no this is not it. From what I've seen this affects the compiler flags -Werr, not anything to do with the configure script. -- Sincerely, David Walluck [EMAIL PROTECTED]
Re: [Cooker] Cooker Compile
So sprach Edward Avis am Sun, Jul 08, 2001 at 11:56:27AM +0100: Probably not as much as the hype suggests. But I think it is noticeable (5% to 10% is the figure touted for Pentium optimized gcc versus i386 gcc). I doubt that 5% are actually noticeable. processing, SETI@Home). But in those cases the standard i386 build Well, SETI@Home of course cannot be compiled as it's closed source. might contain all the possible assembler-optimized routines for different i386-compatible processors and choose between them at run time. Yep. Personally, I am thinking about rebuilding the Mandrake packages for 386 and 486 processors, so I'd like the installer to cope with that. Yes. I also think that other optimization techniques are better suited for performance increase. I just tested Debian, and it simply felt faster/more responsive than Mandrake, although Debian is purely 386 optimized. I wouldn't shed a single tear if Mandrake dropped i586 optimization... Especially a i586 only firewall (MandrakeSecurity) doesn't make any sense at all to me. No, I rather think that it's counter productive, but well... Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 2 days 2 hours 30 minutes
Re: [Cooker] Cooker Compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jul 2001, Frank Meurer wrote: Nope, we want to change autoconf, to get an option telling it: %configure --ac-msg-warn-means--ac-msg-error (er... didn't follow this thread exactly but...) In some auto-conf'ed packages I find an option something like --treat-warnings-as-errors or --enable-warnings_as_errors (e.g. in mjpegtools). That sounds like it. As long as the 'warnings' are about things which really are a problem, such as 'no libtiff found, building without TIFF support'. We wouldn't want to die on harmless 'warnings' which happen all the time anyway - don't know if there are any such things in most configure scripts though. - -- Ed Avis [EMAIL PROTECTED] Finger for PGP key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7SFo3IMp73jhGogoRAt5eAJ9jKVqGAHTjMsu3q4MgvyBn/iNOnACfaVGU h5vwv7x4EitZjMu+FsmUbnM= =YKxb -END PGP SIGNATURE-
Re: [Cooker] Cooker Compile
Edward, I've just uploaded my script install instructions to the list, perhaps you can modify the script to include the automatic dependancy resolving feature. It's a bash script (I'm a no-no with perl), so it should be EZ to adjust Stefan -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jul 2001, David Walluck wrote: [finding BuildRequires lines for source packages] One thing that would help, as I've detailed earlier, is to normalize the BuildRequires. Even still, sometimes I search on romfind.net when a package complains of a depdency that doesn't seem to exist anywhere in cooker. Then once I find what package it is, installing it will usually fix any depdency problems. Finding the missing dependency is the key of course. Brute force won't really help that. The method I proposed would find the missing dependency, because it would try *all* the packages. Every single one. It would be rather slow, and it would grind your hard disk rather a lot, but it would find the necessary set of packages in the end. Of course doing this by hand is not fun. That's why it's best to automate it. Even if the algorithm used is rather stupid compared to a human (who can usually make intelligent guesses about what's needed), it is a lot less work to just leave it running for a few hours and come back to look at the results. - -- Ed Avis [EMAIL PROTECTED] Finger for PGP key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7SDoMIMp73jhGogoRAnNUAJ9SMKoNUlOD8CR22K2GtmP5/pgmWACeMu5j g8l3uyioXlW/0qXHLniMlSk= =CM9J -END PGP SIGNATURE-
Re: [Cooker] Cooker Compile
Hi Wow - nice thinking! If it was accomplished this means that such a self-compiling structure should only need about 20 MB - the rest could be done one night by itself. When one does a ftp install of Debian you need two fd plus drivers for UDMA 66 that is 6 fd. That is all you need to do a ftp install. The very first package is then compressed abot 16 MB. From a theoretical point I would recommend that you copy that plus the compiler and exchange the act package with rpm. Then you could possibly build from there. regards guran
Re: [Cooker] Cooker Compile
Could one of the cooker maintainers give me a simple howto to compile Cooker from the SRPMS. I know how to compile SRPMS, but I was wondering what order I would need to compile them in or if the install program will even recognize *.i686.rpm's instead of the i586 ones. This is an rpm specific question really. Mandrake doesn't seem to provide an option to do this (but Debian might, someone let me know). What I'd love to have is the most minimal set of packages installed, the install would then download and compile the SRPMS according to your specified arch and optflags. I'm actually working on a mechanism like this. The script I'm using first installs the BuildRequires of the src.rpm (with urpmi) and then rebuilds the package. But, the main problem is that the BuildRequires aren't accurate at the moment in cooker. Without the correct BuilRequires you're going to encounter many compile problems. I'm working on fixing them at the moment, but There are still +/- 380 packages that aren't compiling At the moment I'm rebuilding without any -devel package installed (let urpmi install what's required by BuildRequires). If you're interested, I can share the script and setup with you... Stefan
Re: [Cooker] Cooker Compile
On Sat, 7 Jul 2001, Stefan van der Eijk wrote: But, the main problem is that the BuildRequires aren't accurate at the moment in cooker. Without the correct BuilRequires you're going to encounter many compile problems. I'm working on fixing them at the moment, but There are still +/- 380 packages that aren't compiling How are you detecting problems caused by 'non-fatal' missing BuildRequires? As an example: the recent missing requirement for libbzip2_1-devel and libtiff3-devel in kdelibs. If these are not installed then the package will be built without support for the relevant components, but no errors will be flagged. Is there any way to automatically detect this sort of omission? Michael
Re: [Cooker] Cooker Compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 7 Jul 2001, Stefan van der Eijk wrote: What I'd love to have is the most minimal set of packages installed, the install would then download and compile the SRPMS according to your specified arch and optflags. I'm actually working on a mechanism like this. The script I'm using first installs the BuildRequires of the src.rpm (with urpmi) and then rebuilds the package. But, the main problem is that the BuildRequires aren't accurate at the moment in cooker. To be really slick: if a package fails, your script could randomly install some extra packages on the machine (perhaps 50% at random of the total packages in Cooker) and try again to build. If that succeeds, remove some packages and try again, etc. By a kind of binary search you would find the minimal set of packages needed, and those could be added to the spec files as BuildRequires lines. Once all the dependencies are correct, it wouldn't take long to just verify that things work whenever a new package is released, just as a kind of sanity check. It might be good for Mandrakesoft to dedicate a fairly old, slow box to doing this 24 hours a day - getting the latest uploads to Cooker, uninstalling everything except essential packages and what's mentioned in BuildRequires, trying to build it, sending mail to the maintainer if it fails. At the moment I'm rebuilding without any -devel package installed (let urpmi install what's required by BuildRequires). That's a good start, but I have a feeling that the lack of some 'not - -devel' packages may also cause builds to fail. Ideally you'd start from a completely minimal setup - what you'd get if you installed Mandrake and chose the smallest possible selection of packages. If you're interested, I can share the script and setup with you... I would be interested to have a look. If you don't mind me randomly butting in... - -- Ed Avis [EMAIL PROTECTED] Finger for PGP key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7R1sBIMp73jhGogoRAqrxAJ447DwbF86acXoPRXgoqqfEBYB87wCePcvY blukTfOey0aj+V1GMSqSKHk= =HcNN -END PGP SIGNATURE-
Re: [Cooker] Cooker Compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 7 Jul 2001, Michael Brown wrote: [compiling Cooker from scratch, installing only the BuildRequires packages as needed] But, the main problem is that the BuildRequires aren't accurate at the moment in cooker. Without the correct BuilRequires you're going to encounter many compile problems. I'm working on fixing them at the moment, but There are still +/- 380 packages that aren't compiling How are you detecting problems caused by 'non-fatal' missing BuildRequires? As an example: the recent missing requirement for libbzip2_1-devel and libtiff3-devel in kdelibs. If these are not installed then the package will be built without support for the relevant components, but no errors will be flagged. This is really a flaw in the GNU configure mechanism. It would be nice if autoconf's configure scripts allowed you to say: % ./configure --definitely-use-libtiff which would die if the library were not available, rather than quietly leaving out that functionality as at present. At least, I don't think there is currently a way to specify this - anyone know otherwise? - -- Ed Avis [EMAIL PROTECTED] Finger for PGP key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7R1u3IMp73jhGogoRAmziAJ9kv5ggisY+9xNJhKzjcdTafEm7oQCdEeVU jPVyAVVg8iRtKMfW3tt+LbA= =jZMP -END PGP SIGNATURE-
Re: [Cooker] Cooker Compile
Michael Brown wrote: On Sat, 7 Jul 2001, Stefan van der Eijk wrote: But, the main problem is that the BuildRequires aren't accurate at the moment in cooker. Without the correct BuilRequires you're going to encounter many compile problems. I'm working on fixing them at the moment, but There are still +/- 380 packages that aren't compiling How are you detecting problems caused by 'non-fatal' missing BuildRequires? As an example: the recent missing requirement for libbzip2_1-devel and libtiff3-devel in kdelibs. If these are not installed then the package will be built without support for the relevant components, but no errors will be flagged. Is there any way to automatically detect this sort of omission? This is one of the tough ones and I don't know how to solve it... But perhaps we could compare the Provides and Requires of the resulting package against a known (cooker) package. Stefan
Re: [Cooker] Cooker Compile
Edward Avis wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 7 Jul 2001, Michael Brown wrote: [compiling Cooker from scratch, installing only the BuildRequires packages as needed] But, the main problem is that the BuildRequires aren't accurate at the moment in cooker. Without the correct BuilRequires you're going to encounter many compile problems. I'm working on fixing them at the moment, but There are still +/- 380 packages that aren't compiling How are you detecting problems caused by 'non-fatal' missing BuildRequires? As an example: the recent missing requirement for libbzip2_1-devel and libtiff3-devel in kdelibs. If these are not installed then the package will be built without support for the relevant components, but no errors will be flagged. This is really a flaw in the GNU configure mechanism. It would be nice if autoconf's configure scripts allowed you to say: % ./configure --definitely-use-libtiff Then the developer would need to put that in the .spec file -- %configure --definitely-use-libtiff Why not then put in a BuildRequires libtiff-devel? which would die if the library were not available, rather than quietly leaving out that functionality as at present. At least, I don't think there is currently a way to specify this - anyone know otherwise? - -- Ed Avis [EMAIL PROTECTED] Finger for PGP key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7R1u3IMp73jhGogoRAmziAJ9kv5ggisY+9xNJhKzjcdTafEm7oQCdEeVU jPVyAVVg8iRtKMfW3tt+LbA= =jZMP -END PGP SIGNATURE-
Re: [Cooker] Cooker Compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 7 Jul 2001, Stefan van der Eijk wrote: [compiling Cooker from scratch, installing only the BuildRequires packages as needed] How are you detecting problems caused by 'non-fatal' missing BuildRequires? As an example: the recent missing requirement for libbzip2_1-devel and libtiff3-devel in kdelibs. If these are not installed then the package will be built without support for the relevant components, but no errors will be flagged. It would be nice if autoconf's configure scripts allowed you to say: % ./configure --definitely-use-libtiff Then the developer would need to put that in the .spec file Why not then put in a BuildRequires libtiff-devel? Ah. So this isn't the answer. But how about: % ./configure - --definitely-use-everything-possible-including-the-kitchen-sink-and-die-if-it-is-not-there (Fortunately, GNU tools allow you to abbreviate long options.) This would make sure that anything that could be compiled in, is compiled in. A real pain if you're trying to build XEmacs on say Solaris, but useful for the RPM developer (and not a real burden for the user, since dependencies can be dealt with for you). You could override this option: % ./configure --definitely-use-everything --no-libtiff Then you explicitly have to ask for certain things to be skipped if you know you're not using them. But they won't just silently fail. (Well, it's pretty much 'silently' since the warning messages get lost in the noise of messages from configure, make and rpm.) - -- Ed Avis [EMAIL PROTECTED] Finger for PGP key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7R3K6IMp73jhGogoRAm3AAJ4+tbLBdoYyZ8XD11BmJ28UUtOFWQCePnKg QpUKmiJpP3DvqjdSxmQKIHQ= =sfy4 -END PGP SIGNATURE-
Re: [Cooker] Cooker Compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 7 Jul 2001, Edward Avis wrote: [what BuildRequires dependencies should source packages include? Surely packages like bash should be considered 'essential' and don't need to be listed.] How about this as a baseline: the setup you get when you buy a Mandrake boxed set and choose the 'newbie install' hitting Enter for every option. This includes make and gcc, but not that many -devel packages. And how about a package 'essential-devel' which depends on gcc, make and all the other devel stuff included in a Mandrake default install. This package wouldn't contain any files, it would just act as a convenient collection of dependencies, so that if essential-devel is installed you know the basic stuff is there. Packages could then list: BuildRequires: essential-devel = 8.0 along with separate BuildRequires lines for more exotic stuff that isn't part of the basic install. - -- Ed Avis [EMAIL PROTECTED] Finger for PGP key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7R3QcIMp73jhGogoRAmYfAJ9IKDMJdcsxWKfrp5gpFLPddvRt9wCgg+v+ YU/GAjCRTUWtEDGNNeUFVek= =HRhZ -END PGP SIGNATURE-
Re: [Cooker] Cooker Compile
[what BuildRequires dependencies should source packages include? Surely packages like bash should be considered 'essential' and don't need to be listed.] How about this as a baseline: the setup you get when you buy a Mandrake boxed set and choose the 'newbie install' hitting Enter for every option. This includes make and gcc, but not that many -devel packages. And how about a package 'essential-devel' which depends on gcc, make and all the other devel stuff included in a Mandrake default install. This package wouldn't contain any files, it would just act as a convenient collection of dependencies, so that if essential-devel is installed you know the basic stuff is there. Packages could then list: BuildRequires: essential-devel = 8.0 Then you'll need to install one package that Provides: essential-devel. I'm not sure if this is the way to go, it's got an artificial feeling... along with separate BuildRequires lines for more exotic stuff that isn't part of the basic install. The result of the BR march should be that no matter which package you're going to rebuild, if you install the BuildRequires, a (hopefully) good package is going to come out. It's all got todo with closing the gaps in the dependancies. How these gaps are going to be closed will need to be seen, probably each case will find it's own solution. Hmmm... let me upload todays result ;-) Stefan
RE: [Cooker] Cooker Compile
On Fri, 6 Jul 2001, Robert Shade wrote: To answer your question, I am not sure what you refer to as 'install program'. The Mandrake Install program... I mean could you recompile the SRPMS, but them in a directory on a separate HD, boot with the mandrake HD bootfloppy image, and use them to install Mandrake? Robert Shade [EMAIL PROTECTED] Certainly if they are named i586... I don't know at the moment how to make it look for i686, athlon, etc, but hopfully it's as easy as changing one line in a config file somewhere. -- Sincerely, David Walluck [EMAIL PROTECTED]
Re: [Cooker] Cooker Compile
On Sat, 7 Jul 2001, Stefan van der Eijk wrote: This is one of the tough ones and I don't know how to solve it... But perhaps we could compare the Provides and Requires of the resulting package against a known (cooker) package. The only way to solve it is to use manual BuildRequires where the package maintaier is actually paying attention. You could try going through all of rpm --requires for a package but this is actually slower than doing it by hand. Also, keep in mind when you are doing the Requires that I think you are supposed to generalize (normalize) the name, e.g. package libfoo2-devel - foo2-devel. This way, older rpms work too. If libfoo2-devel doesn't provide foo2-devel, then perhaps it should. I have said before that I hate the Debian naming scheme, for many reasons, but this is one of them. Also note this: If I have libfoo1 on my system, and now libfoo2 is needed in say Mandrake 8.1, I no longer need libfoo1. I am wishing for a script that would go through and remove packages which no longer have dependencies. Something like urpmi, but backwards. I usee rpme, but this seems to be as useful as rpm -e or less :) What I dislike most is that both libfoo1-devel and libfoo2-devel can own a file called /usr/include/foo.h. When you rpm --verify libfoo1-devel libfool2-devel, one of these packages will have missing, or checksum errors on files, particularly those shared by both in /usr/include. I have always ran the rpmverify script in contribs looking for problems. Too bad Mandrake doesn't use this, as I think pontentially half of our problems would be avoided before the release. I am not joking. Almost all the problems I see day to day with cooker is poorly managed packages. Yes, this is normal for a system in flux, but can easily be avoided. As an example, the recent broken kdebase package with most of its files missing would have been caught immediately. Again, with the current rpm, packages like libfoo1-devel and libfoo2-devel leave old unused libraries on the system, and make it impossible for rpmverify scripts to detect tampering, as checksum errors are going to occur naturally, even if some hacker has not modified the file. I could rant about this more, but I was only trying to be helpful to you as you attempt to work out the Requires issues in Cooker for your script. Fortunately, you have write access :) -- Sincerely, David Walluck [EMAIL PROTECTED]
Re: [Cooker] Cooker Compile
On Sat, 7 Jul 2001, Stefan van der Eijk wrote: The result of the BR march should be that no matter which package you're going to rebuild, if you install the BuildRequires, a (hopefully) good package is going to come out. It's all got todo with closing the gaps in the dependancies. How these gaps are going to be closed will need to be seen, probably each case will find it's own solution. Hmmm... let me upload todays result ;-) Stefan Sorry, I am writing all replies to this subject all at once, so I missed what this one was in reference to -- maybe the binary search algorithm? Anyway this would be pointless, because the point of Requires is so that I don't have to install 1000 rpms that I don't need. As I've said, I have done this and it's not fun. What's more, the package still isn't guaranteed to compile. One thing that would help, as I've detailed earlier, is to normalize the BuildRequires. Even still, sometimes I search on romfind.net when a package complains of a depdency that doesn't seem to exist anywhere in cooker. Then once I find what package it is, installing it will usually fix any depdency problems. Finding the missing dependency is the key of course. Brute force won't really help that. -- Sincerely, David Walluck [EMAIL PROTECTED]
Re: [Cooker] Cooker Compile
Robert Shade a crit : I love Mandrake, but I've also made my own LinuxFromScratch (www.linuxfromscratch.org). While I like the speed increase I get when compiling from scratch. I like the tools that come with Mandrake not to mention the ease of RPM package management. Could one of the cooker maintainers give me a simple howto to compile Cooker from the SRPMS. I know how to compile SRPMS, but I was wondering what order I would need to compile them in or if the install program will even recognize *.i686.rpm's instead of the i586 ones. Robert Shade [EMAIL PROTECTED] I had similar problem and turn arround. Have find a very small utilitary whitch could be include in cookers packages in order to solve such RPM management Name of package : checkinstall Pascalou -- Bonjour a tous Je suis actuellement au Pays de Galles pour 1 mois et demi, Quelqu un peut il me donner des nouvelles de France de temps en temps sur NG ? -+- LT in : GNU - Neuneu vote [ Oui ] fr.rec.france.info.ng -+-
Re: [Cooker] Cooker Compile
On Sat, 7 Jul 2001, Stefan van der Eijk wrote: This is really a flaw in the GNU configure mechanism. It would be nice if autoconf's configure scripts allowed you to say: % ./configure --definitely-use-libtiff Then the developer would need to put that in the .spec file -- %configure --definitely-use-libtiff Why not then put in a BuildRequires libtiff-devel? First of all, it is not a problem with rpm %configure, but a potential problem with configure.in scripts. When I write autoconf scripts, I always AC_MSG_ERROR on a missing package, some people just AC_MSG_WARN, others just assume you don't want it to be supported if this feature is optional. The problem with the last two methods (which I didn't generally approve of in the first palce, regardless of rpm), is the fact that rpm --requires will miss this. This is why I wrote recently about missing BuildRequires in xchat. You'd never catch them, because if you built the package without a particular dependency installed (say without python), it would build fine. This is relatively harmless if you build from the src rpm, but for a user installing the binary rpm, rpm warns him that he needs python, because the person who originally built the rpm had python on his system, even if he didn't note this in either one of Requires or BuildRequires. Again, this is an argument for being careful and doing the dependencies by hand. The only sure way to catch it is to start installing rpms with urpmi on a bare system as Stefan is doing, and as I hhave done in the past. -- Sincerely, David Walluck [EMAIL PROTECTED]
Re: [Cooker] Cooker Compile
On Sat, 7 Jul 2001, Stefan van der Eijk wrote: But, the main problem is that the BuildRequires aren't accurate at the moment in cooker. Without the correct BuilRequires you're going to encounter many compile problems. I'm working on fixing them at the moment, but There are still +/- 380 packages that aren't compiling I am worried because I have done a full install of all packages at one point and still get many compile errors. I wonder how the package maintainers built the packages in the first place... certainly not in a true 8.0 environment. At the moment I'm rebuilding without any -devel package installed (let urpmi install what's required by BuildRequires). If you're interested, I can share the script and setup with you... Stefan Sure, you may e-mail the script directly if you wish. It is probably in perl, which is not my strong suit, but maybe an excuse to learn? I will definately test it anyway. The idea would be that you only needed basic compiler et. al, anything that was downloaded as a binary, for example gcc, would be compiled at the final stage of the install, after all the other packages were built successfully. Again, without an optimized compiler, you may also fail to get optimized packages, but as I have said in pervious e-mails, lots of packages have problems with some optimizations thata re supposedly safe, meaning they will fail to compile. So the question becomes, if only the optflags that were originally used are safe, what benefits do we get from recompiling? In my case I wonder if -march=athlon -O2 is even faster than -O3 -march=pentiumpro. Again, in some cases we are talking a 'mere' 5% increase, but I have always thought one of the main advantages to having the source code was so that you could make the most from your hardware. In any case, I will galdly test your script and report any problems. -- Sincerely, David Walluck [EMAIL PROTECTED]
Re: [Cooker] Cooker Compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 7 Jul 2001, Stefan van der Eijk wrote: What I'd love to have is the most minimal set of packages installed, the install would then download and compile the SRPMS according to your specified arch and optflags. I'm actually working on a mechanism like this. To be really slick: if a package fails, your script could randomly install some extra packages on the machine (perhaps 50% at random of the total packages in Cooker) and try again to build. If that succeeds, remove some packages and try again, etc. By a kind of binary search you would find the minimal set of packages needed, Hmmm... Would that actually work? For sure. Brute force methods always work, it's just that they can be a bit slow. Let me illustrate what I mean with an example. Suppose that you install your minimal+BuildRequires system and a package P fails to rpm - --rebuild. Suppose for the sake of argument that there are only ten more packages included in Cooker (!), numbered 0 to 9 inclusive. This is what happens: Installed: (none), not installed: 0123456789. Try to build P - fails. Pick randomly half of the remaining packages and install. Installed: 02469, not installed: 13578. Try to build P - fails. Pick randomly half (three) of the remaining packages and install. Installed: 01234679, not installed: 58. Try to build P - succeeds. At this stage we know that 5 and 8 are not needed. The 'binary search' goes in the other direction - pick half of the installed packages and uninstall them. Installed: 0179, not installed: 2346, not needed: 58. Try to build P - succeeds. We know that 2 3 4 and 6 are not needed. Uninstall half of the installed packages. Installed: 17, not installed: 09, not needed: 234568. Try to build P - fails. Install half of the not installed packages - not counting those we already know are not needed. Installed: 179, not installed: 0, not needed: 234568. Try to build P - succeeds. So 0 is not needed. Uninstall half (one) of the installed packages. Installed: 79, not installed: 1, not needed: 0234568. Try to build P - fails. Right, we're coming to the end now. Uninstalling a single package - package number 1 - causes P to break. So we know that 1 is needed, and we can install it always for the tests further on. Needed: 1, installed: 79, not installed: (none), not needed: 0234568. So packages 1, 7 and 9 are installed - 1 is definitely needed and we're testing whether we need 7 and/or 9. As an optimization, remember that we previously tried building with 1 7 and 9 installed, and it worked. So uninstall half of the installed packages at random, as before. (1 is known to be needed, so we won't uninstall that.) Needed: 1, installed: 9, not installed: 7, not needed: 0234568. Try to build P - succeeds. We know that 7 is not needed. Uninstall half (one) of the installed packages. Needed: 1, installed: (none), not installed: 9, not needed: 02345678. Try to build P - fails. We know that 9 is needed. We've now assigned every package to either 'needed' or not needed, so the final result is: Needed: 19, not needed: 02345678. So packages 1 and 9 should be added as BuildRequires lines. I hope you can figure out the algorithm from the example above; if not I could write some code to implement and demo it. But I'm sure you do get the idea. I've taken some liberties with the meaning of 'half' - sometimes it rounds up and sometimes down. I think rounding up is needed because when you have only one package left in the 'installed' or 'not installed' pools, then it's no good removing zero packages from that pool. Although actually having just one package left is a special case - - it's this that lets you finally decide whether a package is needed. I mean, there are _so_ many packages in cooker, This process could take a long time to figure out the dependencies for a package, just grinding through the set of other packages. But of course it is nice and quick in the case of a package which lists its dependencies properly: it builds first time, all the not-installed packages are marked as 'not needed', and that's that. Still, it would probably be quicker than doing the job by hand - if, like me, you have a fast computer and slow fingers :-). and if you take along the dependancies it would be hard to pinpoint what is really required. As you can see the method I propose doesn't bother to look at dependencies. It just goes by what works. For instance, a package fails, the script decides to install gnome-core-devel, how would we then know if gnome-libs-devel or gtk+-devel would have been enough? I think it would try gnome-core-devel along with lots of other stuff; if that happened to work then it would try uninstalling things; eventually it would be able to move packages into 'not needed' if it found a combo which worked without them. So in the end, it would figure out the minimal set of
Re: [Cooker] Cooker Compile
On Sat, 7 Jul 2001, guran wrote: When one does a ftp install of Debian you need two fd plus drivers for UDMA 66 that is 6 fd. That is all you need to do a ftp install. The very first package is then compressed abot 16 MB. Well, Mandrake can do an FTP install too, off of only one floppy disk, but it does not allow you to build a distribution from source depdendencies. -- Sincerely, David Walluck [EMAIL PROTECTED]
Re: [Cooker] Cooker Compile
Robert Shade wrote: Could one of the cooker maintainers give me a simple howto to compile Cooker from the SRPMS. I know how to compile SRPMS, but I was wondering what order I would need to compile them in or if the install program will even recognize *.i686.rpm's instead of the i586 ones. This is an rpm specific question really. Mandrake doesn't seem to provide an option to do this (but Debian might, someone let me know). What I'd love to have is the most minimal set of packages installed, the install would then download and compile the SRPMS according to your specified arch and optflags. THis may not be too easily because frequently I grab an SRPM for cooker and it fails with a compiler error. Also compiling with certain options, especially -On, n 2 can cause problems. To answer your question, I am not sure what you refer to as 'install program'. You could for example, make your own depslist that urpmi can use to upgrade your system, but like I said, I don't think it handles sources. What I suggest, is starting with an already installed mandrake system, simply add something like this to you ~/.rpmrc: buildarchtranslate: i686: athlon arch_compat: athlon: i686 buildarch_compat: athlon: i686 optflags: athlon -O3 -march=athlon Of course in your case you may need to replace athlon with pentiumpro. i686 is the output of uname -m. -- Sincerely, David Walluck [EMAIL PROTECTED]
RE: [Cooker] Cooker Compile
To answer your question, I am not sure what you refer to as 'install program'. The Mandrake Install program... I mean could you recompile the SRPMS, but them in a directory on a separate HD, boot with the mandrake HD bootfloppy image, and use them to install Mandrake? Robert Shade [EMAIL PROTECTED]
Re: [Cooker] Cooker Compile
Robert Shade [EMAIL PROTECTED] writes: I love Mandrake, but I've also made my own LinuxFromScratch (www.linuxfromscratch.org). While I like the speed increase I get when compiling from scratch. I like the tools that come with Mandrake not to mention the ease of RPM package management. Could one of the cooker maintainers give me a simple howto to compile Cooker from the SRPMS. I know how to compile SRPMS, but I was wondering what order I would need to compile them in or if the install program will even recognize *.i686.rpm's instead of the i586 ones. You can use rpm-rebuilder package which contains shell scripts to help rebuild a set of packages. -- Fred - May the source be with you
