From: D. S. B. <bar...@fa...> - 2005-01-01 12:27:22
|
Hello Kern, I added a second wget target to grab update packages and a second source for base packages. By the way, both the base and update targets should only download a file if it is newer than the local copy, thus you can periodically run the update target to get new stuff. The second base source is because SuSE provides src.rpm and nosrc.rpm packages. nosrc packages could be stuff like themes which actually have no source code or packages for which they can't deliver source. They are a standard srpm with just an install section, no build. This requires some python changes which I leave to you since I know next to nothing here. 1. do_packages() in buildpackages needs to recognize .nosrc.rpm as well as src.rpm. 2. buildinit needs to parse filenames into packagename-version-release and throw out the older versions so that paths.unbuilt only contains a set of newest packages. Regards, Scott |
From: Kern S. <ke...@si...> - 2005-01-01 16:22:21
|
On Sat, 2005-01-01 at 07:27 -0500, D. Scott Barninger wrote: > Hello Kern, > > I added a second wget target to grab update packages and a second source > for base packages. By the way, both the base and update targets should > only download a file if it is newer than the local copy, thus you can > periodically run the update target to get new stuff. > > The second base source is because SuSE provides src.rpm and nosrc.rpm > packages. nosrc packages could be stuff like themes which actually have > no source code or packages for which they can't deliver source. They are > a standard srpm with just an install section, no build. > > This requires some python changes which I leave to you since I know next > to nothing here. > > 1. do_packages() in buildpackages needs to recognize .nosrc.rpm as well > as src.rpm. OK, no problem, but why do they really need a .nosrc.rpm? Do I need to treat it differently, i.e. should I still do rpmbuild ...? > 2. buildinit needs to parse filenames into packagename-version-release > and throw out the older versions so that paths.unbuilt only contains a > set of newest packages. Yes, I'll be working on this shortly. I need to do it for both .src.rpm packages, and also for .rpms, because I want to be able to directly download prebuilt rpms and at the user's option skip doing the build of the src.rpms. Best regards, Kern |
From: D. S. B. <bar...@fa...> - 2005-01-01 16:44:31
Attachments:
libxml2-python.spec
|
On Sat, 2005-01-01 at 17:22 +0100, Kern Sibbald wrote: > OK, no problem, but why do they really need a .nosrc.rpm? Do I need to > treat it differently, i.e. should I still do rpmbuild ...? > Not sure about the why, it just seems that if there is no actual "build" of the software in the usual sense they make it nosrc rather than src. For example ftp://ftp.ale.org/pub/suse/i386/update/9.0/rpm/src/libxml2-python-2.5.10-62.nosrc.rpm uses the libxml2 tarball but doesn't recompile the libxml2 lib file but copies the one installed by libxml2 package and then builds the python package. Spec attached. It's not handled any differently by rpmbuild. |
From: Kern S. <ke...@si...> - 2005-01-01 19:56:25
|
On Sat, 2005-01-01 at 07:27 -0500, D. Scott Barninger wrote: > Hello Kern, > > I added a second wget target to grab update packages and a second source > for base packages. By the way, both the base and update targets should > only download a file if it is newer than the local copy, thus you can > periodically run the update target to get new stuff. > > The second base source is because SuSE provides src.rpm and nosrc.rpm > packages. nosrc packages could be stuff like themes which actually have > no source code or packages for which they can't deliver source. They are > a standard srpm with just an install section, no build. > > This requires some python changes which I leave to you since I know next > to nothing here. > > 1. do_packages() in buildpackages needs to recognize .nosrc.rpm as well > as src.rpm. I think I have change my mind a bit on this. I took a look at the Fedora release and there are no nosrc.rpm files. I'm not sure what I would like to do. I hesitate, because my first reaction is that SuSE should not be creating a new extension that seems to serve no purpose. Until I can understand why it is needed, I'd like to do nothing. In the mean time, I'd recommend that you write a small script (or I'll write one for you) that simply copies all .nosrc.rpm extensions into .src.rpm. -- Best regards, Kern |
From: D. S. B. <bar...@fa...> - 2005-01-02 13:09:40
|
On Sat, 2005-01-01 at 20:56 +0100, Kern Sibbald wrote: > On Sat, 2005-01-01 at 07:27 -0500, D. Scott Barninger wrote: > > Hello Kern, > > > > I added a second wget target to grab update packages and a second source > > for base packages. By the way, both the base and update targets should > > only download a file if it is newer than the local copy, thus you can > > periodically run the update target to get new stuff. > > > > The second base source is because SuSE provides src.rpm and nosrc.rpm > > packages. nosrc packages could be stuff like themes which actually have > > no source code or packages for which they can't deliver source. They are > > a standard srpm with just an install section, no build. > > > > This requires some python changes which I leave to you since I know next > > to nothing here. > > > > 1. do_packages() in buildpackages needs to recognize .nosrc.rpm as well > > as src.rpm. > > I think I have change my mind a bit on this. > > I took a look at the Fedora release and there are no nosrc.rpm files. > I'm not sure what I would like to do. I hesitate, because my first > reaction is that SuSE should not be creating a new extension that seems > to serve no purpose. Until I can understand why it is needed, I'd like > to do nothing. > > In the mean time, I'd recommend that you write a small script (or I'll > write one for you) that simply copies all .nosrc.rpm extensions > into .src.rpm. > > nosrc2src.pl now in cvs. |