Re: [Cooker] the future of BuildRequires?

2001-05-31 Thread François Pons

Stefan van der Eijk [EMAIL PROTECTED] writes:

 - Exact packagesnames need to be in BuildRequires if automated BuidRequires
 installation is to be done (more automatic installation later). Maybe urpmi can
 be tought to figure out provides packages, but at the moment it can't:
 
 [root@taz root]# urpmi libjpeg-devel
 no package named libjpeg-devel
 
 [root@taz root]# urpmi jpeg-devel
 no package named jpeg-devel
 
 [root@taz root]# urpmi libjpeg62-devel
 everything already installed
 
 urpmi only understands libjpeg62-devel

Yes, but urpmi should (I say should as it was running like that before but now
it only install dependancies) allow you to install the source package as :
  sudo /usr/sbin/urpmi /SRPMS/rpmtools-2.3-22mdk.src.rpm
will install or upgrade package needed according to BuildRequires.

I need to fix why currently it only install the dependancies and not the src.rpm
itself...

François.




Re: [Cooker] the future of BuildRequires?

2001-05-31 Thread Stefan van der Eijk



- Exact packagesnames need to be in BuildRequires if automated BuidRequires
installation is to be done (more automatic installation later). Maybe urpmi can
be tought to figure out provides packages, but at the moment it can't:

[root@taz root]# urpmi libjpeg-devel
no package named libjpeg-devel

[root@taz root]# urpmi jpeg-devel
no package named jpeg-devel

[root@taz root]# urpmi libjpeg62-devel
everything already installed

urpmi only understands libjpeg62-devel


Yes, but urpmi should (I say should as it was running like that before but now
it only install dependancies) allow you to install the source package as :
  sudo /usr/sbin/urpmi /SRPMS/rpmtools-2.3-22mdk.src.rpm
will install or upgrade package needed according to BuildRequires.

In short, I'm doing it something like this:

for i in `rpm -qpR to_be_built.src.rpm`
do
   /usr/sbin/sudo --auto $i  urpmi_output_of_to_be_built.src.rpm.txt
   done

rpm --rebuilt to_be_built.src.rpm

for i in `cat urpmi_output_of_to_be_built.src.rpm.txt | grep ## | cut 
-d   -f1`
   do
   sudo /usr/sbin/urpme --auto $i
   done

I need to fix why currently it only install the dependancies and not the src.rpm
itself...

Exactly. As you see above I don't need to be able to install the 
src.rpm, I just need urpmi to be able to install the (build-) 
dependancies of the src.rpm.

Stefan

PS: I found out today that the script above _can_ be dangerous -- when 
inbetween there are some updated packages, (say bzip2 got updated) and 
it needs to install libbzip2_1-devel (and also updated libbzip2, because 
urpmi figures out the dependancy -- libbzip2_1-devel is newer and it 
updated libbzip2 to the same level). Then later on both libbzip2_1-devel 
and libbzip2 get removed... bummer.





[Cooker] the future of BuildRequires?

2001-05-26 Thread Stefan van der Eijk

Hi,

A while ago flepied let a script loose on cooker to get the
BuildRequires of the packages back inline.

This week I reinstalled my buildmachine, and started recompiling
cooker. I found out that many packages have incorrect BuildRequires in
them. Some of them point to non-existant packages. Some point to
something that is provided by a package, but urpmi doesn't install the
package.

Eventually I managed to get most required packages installed. With some
scripting the packages that were correct in the BuildRequires went
correctly. The others required figuring out.

Observations:

- BuildRequires are (mostly) only updated when the developer in charge 
gets a signal todo so. The signal can be
1/ that the package doesn't compile successfully and the developper 
figures out which package needs to be added
2/ a (cooker-) user tells the developper that it needs to be added. 
Mostly the cooker user experiences the reason above.

- Once a package is installed on the developpers machine, the chance is
small that it will be added to the BuildRequires (of a new package) -- 
since the developer doesn't get a signal (the package is already there, 
the package compiles fine).

- The danger with BuildRequires is that it's easy to put in too many.
For instance, if a package requires gdk-pixbuf-devel and 
libjpeg62-devel, only gdk-pixbuf-devel needs to be in the BuildRequires 
(since gdk-pixbuf-devel needs libjpeg in order to exist).

- Exact packagesnames need to be in BuildRequires if automated 
BuidRequires installation is to be done (more automatic installation 
later). Maybe urpmi can be tought to figure out provides packages, but 
at the moment it can't:

[root@taz root]# urpmi libjpeg-devel
no package named libjpeg-devel

[root@taz root]# urpmi jpeg-devel
no package named jpeg-devel

[root@taz root]# urpmi libjpeg62-devel
everything already installed

urpmi only understands libjpeg62-devel


OK. How can we go about with BuildRequires?

1/ Scrap all BuildRequires, those things are a mess at the moment 
anyway, the only thing that counts for the end-user are the Requires, 
and those are mostly put into the package with RPM.

For developers it's also easy: just make sure all the packages are 
installed, and you'll be fine ;-)

2/ Keep going as we do now. Add / remove / modify BuildRequires as time 
goes by, during a freeze let a script run over the distro to check if 
things are OK.

3/ Make some sort of system that checks the BuildRequires regularly, 
without hampering the development process (no updated packages due to 
rebuilds, etc).

Each option has it's pro's and cons.


Proposal for option 3:

At this moment I've got some scripts running on my box that rebuild the 
distro weekly. They do a reasonable job (they often sense when things 
get broken, etc), once all the BuildRequires are installed on the box.

Now, since BuildRequires are an important part of the distro, I'd also 
like to let the script check the BuildRequires. I envision this as follows:

Install a bare-bones development system.
The script will start rebuilding packages:
1/ it'll do a rpm --rebuild on the package,
2/ then fires off an urpmi to install the BuildRequires packages 
(resulting from the first failed rpm --rebuild)
3/ rebuilds the package (and stores the buildoutput somewhere)
4/ removes the packages it just installed in order to build the package

This allows you not only to check if the package builds correctly, but 
also checks the BuildRequires. If this were to be done on a seperate 
machine (has nothing todo with the cooker build process), and would only 
have the results available, then it could benefit cooker tremendously.

Actions:

Although this stuff is not of much use to end-users (the Mandrake people 
might be interested), perhaps we can have a discussion about this topic, 
and we'll see where it goes from there?

Stefan van der Eijk

Disclaimer: My goals is not to complain about what's wrong, but rather 
to observe and bring up area's where improvements can be made. I might 
be completely off-course though.