[opensuse-buildservice] spec files: package source: file or link?
Hi, at least in one suse spec file I saw as source an url to the web site with our source files. I wonder: - is this only for looking for new versions? - If I keep the url in the package, will I still need to provide the downloaded file or will the build server do that for me? - is it better to replace it with the file name, and provide the downloaded and uploaded source .tar.gz? as you can see, I'm a rpm newby, so help is very welcome. Regards, Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Fri, Sep 22, 2006 at 09:21:05AM +0200, Andreas Jellinghaus wrote:
Hi,
at least in one suse spec file I saw as source an url to the web site with our source files.
I wonder: - is this only for looking for new versions? - If I keep the url in the package, will I still need to provide the downloaded file or will the build server do that for me? - is it better to replace it with the file name, and provide the downloaded and uploaded source .tar.gz?
as you can see, I'm a rpm newby, so help is very welcome.
This is only for informational purposes. You still have to provide the file itself as if you specified the name only. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
Robert Schiele wrote:
On Fri, Sep 22, 2006 at 09:21:05AM +0200, Andreas Jellinghaus wrote:
Hi,
at least in one suse spec file I saw as source an url to the web site with our source files.
I wonder: - is this only for looking for new versions? - If I keep the url in the package, will I still need to provide the downloaded file or will the build server do that for me? - is it better to replace it with the file name, and provide the downloaded and uploaded source .tar.gz?
as you can see, I'm a rpm newby, so help is very welcome.
This is only for informational purposes. You still have to provide the file itself as if you specified the name only.
Depends, my own build scripts can actually download the file (if it's
not locally cached yet) before triggering the build ;)
IMO a full URL is much better because you can directly see where the
file comes from, and it has no drawback as rpmbuild will just strip
out the URL part and keep the filename part to do its job.
But, as Robert wrote, it's just for informational purpose as rpmbuild
ignores the URL (and expects the file to be present in
/usr/src/packages/SOURCES/ anyway).
cheers
--
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
On 2006-09-22 12:00:04 +0200, Pascal Bleser wrote:
Depends, my own build scripts can actually download the file (if it's not locally cached yet) before triggering the build ;)
and the build service soon too. there was a Google summer of code project for upstream integration. that should be part of it. hopefully not too far away you have an button to do the version update and it will patch spec file and gets the new tarball. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Marcus Rueckert wrote:
On 2006-09-22 12:00:04 +0200, Pascal Bleser wrote:
Depends, my own build scripts can actually download the file (if it's not locally cached yet) before triggering the build ;)
and the build service soon too. there was a Google summer of code project for upstream integration. that should be part of it.
Great. Actually it's not that difficult to implement, as you "just" need to parse the spec file and then trigger wget or curl on the URL + copy the resulting download to SOURCES/ A cache would obviously be quite useful, as we don't want to download the file with every build. Maybe a fixed size disk cache and remove sources older than x days... ? (arguably the most complex part to implement) Hmm... maybe using a caching proxy (squid) for downloading the Source URLs would be a lot easier, as it already does exactly that, based on the available disk cache size (which is even better). It would also solve the "problem" that you have different build hosts that would need to share the cache to make it efficient (obviously a single squid host used by all build hosts is a _lot_ easier than shared storage ;)).
hopefully not too far away you have an button to do the version update and it will patch spec file and gets the new tarball.
Yes, possibly.
cheers
--
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
On 2006-09-22 12:37:36 +0200, Pascal Bleser wrote:
Marcus Rueckert wrote:
and the build service soon too. there was a Google summer of code project for upstream integration. that should be part of it.
Great. Actually it's not that difficult to implement, as you "just" need to parse the spec file and then trigger wget or curl on the URL + copy the resulting download to SOURCES/
it is not the idea to download it for every build. but replace the old upstream tarball with it. and of course fetching from various SCM systems is planned too. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Friday 22 September 2006 12:37 schrieb Pascal Bleser:
Marcus Rueckert wrote:
On 2006-09-22 12:00:04 +0200, Pascal Bleser wrote:
Depends, my own build scripts can actually download the file (if it's not locally cached yet) before triggering the build ;)
and the build service soon too. there was a Google summer of code project for upstream integration. that should be part of it.
Great. Actually it's not that difficult to implement, as you "just" need to parse the spec file and then trigger wget or curl on the URL + copy the resulting download to SOURCES/
it is a bit more, since we do not want to rely on .spec files, tar ball validation is needed and we want also support cvs/svn checkouts.
A cache would obviously be quite useful, as we don't want to download the file with every build.
yes
Maybe a fixed size disk cache and remove sources older than x days... ? (arguably the most complex part to implement)
no, we do not want to loose the history within the source repository. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Adrian Schröter wrote:
Am Friday 22 September 2006 12:37 schrieb Pascal Bleser:
Marcus Rueckert wrote:
Depends, my own build scripts can actually download the file (if it's not locally cached yet) before triggering the build ;) and the build service soon too. there was a Google summer of code
On 2006-09-22 12:00:04 +0200, Pascal Bleser wrote: project for upstream integration. that should be part of it. Great. Actually it's not that difficult to implement, as you "just" need to parse the spec file and then trigger wget or curl on the URL + copy the resulting download to SOURCES/
it is a bit more, since we do not want to rely on .spec files, tar ball validation is needed and we want also support cvs/svn checkouts.
Ok. What would you validate besides the fact that it actually is what it says (that a .tar.gz is effectively a .tar.gz) ? And yay for cvs/svn checkouts :) Source: http://..../foobar@1424 or Source: :pserver:..../module@TAG :)
A cache would obviously be quite useful, as we don't want to download the file with every build.
yes
Maybe a fixed size disk cache and remove sources older than x days... ? (arguably the most complex part to implement)
no, we do not want to loose the history within the source repository.
So you really want to commit the sources into the repository.
Hmm.. ok, that's one approach.
At Packman we decided against it to avoid bloating the repository with
gigabytes of tarballs. Obviously, this is only consistent with the
premise that the source tarballs are still available.
Your approach is more consistent, no question, if you have enough
storage space for the repository ;D
BTW, does that mean you keep a history of the BS projects in... what,
SVN ?
cheers
--
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
Pascal Bleser wrote:
Adrian Schröter wrote:
Am Friday 22 September 2006 12:37 schrieb Pascal Bleser:
Marcus Rueckert wrote:
Depends, my own build scripts can actually download the file (if it's not locally cached yet) before triggering the build ;) and the build service soon too. there was a Google summer of code
On 2006-09-22 12:00:04 +0200, Pascal Bleser wrote: project for upstream integration. that should be part of it. Great. Actually it's not that difficult to implement, as you "just" need to parse the spec file and then trigger wget or curl on the URL + copy the resulting download to SOURCES/ it is a bit more, since we do not want to rely on .spec files, tar ball validation is needed and we want also support cvs/svn checkouts.
Ok. What would you validate besides the fact that it actually is what it says (that a .tar.gz is effectively a .tar.gz) ?
And yay for cvs/svn checkouts :) Source: http://..../foobar@1424 or Source: :pserver:..../module@TAG :)
Umm.. actually, to make it work with rpmbuild...
Version: 1424
...
Source: http://..../foobar@%{version}/foobar-%{version}.tar.bz2
Parser needs to interpret it as
svn co http://..../foobar@1424 foobar-1424
tar cjf foobar-1424.tar.bz2 foobar-1424
rm -rf foobar-1424
Already have some specs about the URL specification for those ?
cheers
--
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
participants (5)
-
Adrian Schröter -
Andreas Jellinghaus -
Marcus Rueckert -
Pascal Bleser -
Robert Schiele