[opensuse-packaging] How can I produce two different builds of the same package?
Hi, I need to package a postgresql and a mysql build of the same package, I can do two different builds in the same spec file but the resulting libraries and binaries have the same names. Is there a way to create two rpms with the files from the resulting builds or use two spec files in the same package or am I going to have to rename all the files with the same names? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 19/12/09 08:15, Dave Plater wrote:
Hi, I need to package a postgresql and a mysql build of the same package, I can do two different builds in the same spec file but the resulting libraries and binaries have the same names. Is there a way to create two rpms with the files from the resulting builds or use two spec files in the same package or am I going to have to rename all the files with the same names?
I think you can try with --program-suffix or -program-transform-name http://www.linuxselfhelp.com/gnu/autoconf/html_chapter/autoconf_toc.html#TOC... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 12/19/2009 08:17 PM, Cristian Rodríguez wrote:
On 19/12/09 08:15, Dave Plater wrote:
Hi, I need to package a postgresql and a mysql build of the same package, I can do two different builds in the same spec file but the resulting libraries and binaries have the same names. Is there a way to create two rpms with the files from the resulting builds or use two spec files in the same package or am I going to have to rename all the files with the same names?
I think you can try with --program-suffix or -program-transform-name
http://www.linuxselfhelp.com/gnu/autoconf/html_chapter/autoconf_toc.html#TOC...
Thanks for the clue. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 19/12/09 16:27, Dave Plater wrote:
http://www.linuxselfhelp.com/gnu/autoconf/html_chapter/autoconf_toc.html#TOC...
Thanks for the clue.
add to that the use of update-alternatives(8) to easily switch between those packages. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Sat, 19 Dec 2009 21:27:47 +0200, you wrote:
or use two spec files in the same package
Using more than one spec file is rather common in openSUSE packages. Some examples are graphviz or automake. The only drawback is that you have to keep two or more spec files in sync when you update the package. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
It really depends whether you want to support the mysql and postgresql linked versions of your package bring installed simultaneously. If the answer is yes, then you either need to rename the file or at least put then on distinct paths and then use something like update- alternatives to allow your users to select which version they want. On Dec 19, 2009, at 5:18 AM, "Dave Plater" <dplater@webafrica.org.za> wrote:
Hi, I need to package a postgresql and a mysql build of the same package, I can do two different builds in the same spec file but the resulting libraries and binaries have the same names. Is there a way to create two rpms with the files from the resulting builds or use two spec files in the same package or am I going to have to rename all the files with the same names? Thanks Dave P
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
It really depends whether you want to support the mysql and postgresql linked versions of your package bring installed simultaneously. If the answer is yes, then you either need to rename the file or at least put then on distinct paths and then use something like update- alternatives to allow your users to select which version they want.
On Dec 19, 2009, at 5:18 AM, "Dave Plater" <dplater@webafrica.org.za> wrote:
Hi, I need to package a postgresql and a mysql build of the same package, I can do two different builds in the same spec file but the resulting libraries and binaries have the same names. Is there a way to create two rpms with the files from the resulting builds or use two spec files in the same package or am I going to have to rename all the files with the same names? Thanks Dave P
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
I need to produce two rpms from the same package bacula, one built with -with-postgresql and one -with-mysql, in fact there is an sqlite version as well but if I can make two then I can make three. The resulting
On 12/19/2009 09:31 PM, Luke Imhoff wrote: libraries have the same names but I think the three binaries are identical. Unfortunately rpm doesn't support normal commands like cp in the %files section because that would solve my problem. An idea I've just had is to place them in a different directory and use the %pre section to copy them across to %{_libdir}. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Op zondag 20 december 2009 06:20:24 schreef Dave Plater:
Unfortunately rpm doesn't support normal commands like cp in the %files section because that would solve my problem.
You should use the cp (%__cp) command in the make section of the specfile. In case you want to install the files in directory, create the directory (%__install -d -m 755 ....) and move (%__mv) the files to the directory. Once you have done this, you can list them in the files section of the rpm
An idea I've just had is to place them in a different directory and use the %pre section to copy them across to %{_libdir}.
That's not the right way to do it! -- Richard -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 12/20/2009 01:03 PM, Richard Bos wrote:
Op zondag 20 december 2009 06:20:24 schreef Dave Plater:
Unfortunately rpm doesn't support normal commands like cp in the %files section because that would solve my problem.
You should use the cp (%__cp) command in the make section of the specfile. In case you want to install the files in directory, create the directory (%__install -d -m 755 ....) and move (%__mv) the files to the directory. Once you have done this, you can list them in the files section of the rpm
An idea I've just had is to place them in a different directory and use the %pre section to copy them across to %{_libdir}.
That's not the right way to do it!
I think that the problem is misunderstood, bacula builds with either mysql, postgresql or sqlite support and the built libraries all have the same names but support the three different databases. So at the end of the %build process I have three sets of libraries to be installed in _libdir for bacula-mysql, bacula-postgresql and bacula-sqlite rpms and the last ones to be installed will overwrite the others. If there isn't a way to get osc to build with three different spec files then short of installing them in _libdir/bacula-mysql/, _libdir/bacula-posgresql/ and _libdir/bacula-sqlite/ and then moving them to _libdir in the %pre or %post section of the three different rpms then they have to be built in three different project packages. I once saw a package in build service with two spec files but I can't remember which one it was and whether more than one was used in the package build. Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, did you talk to Kern about modifying Bacula so that it builds these libraries into different names and dynamically loads the correct one? This would allow the user to actually have the DB backend as a configuration option. This could be as primitive as putting the various libraries into different subdirs of _libdir/bacula and adding the correct dir to LD_LIBRARY_PATH of the start script. IMHO any solution you make here should go upstream... An alternative is the use of update-alternatives as mentioned already in this thread. Any "hacking solution" as part of the RPMs or SPEC files is likely to produce much more management overhead for you as the maintainer. You could for example build different subpackages that exclude each other. But then the user would be confronted at installation time to choose the correct database, not so intuitive to the average user as a configuration option. Bottom line is, either Bacula solves this problem or you will have a lot of pain maintaining the RPMs. BTW, are you the author of the RPMs on http://www.bacula.org/en/?page=downloads? If not, maybe you look at the src.rpm that can be found there and how it builds the different DB backend RPMs... And of course you might merge your work back into the "official" Bacula SPEC file... Regards, Schlomo Dave Plater wrote:
On 12/20/2009 01:03 PM, Richard Bos wrote:
Op zondag 20 december 2009 06:20:24 schreef Dave Plater:
Unfortunately rpm doesn't support normal commands like cp in the %files section because that would solve my problem.
You should use the cp (%__cp) command in the make section of the specfile. In case you want to install the files in directory, create the directory (%__install -d -m 755 ....) and move (%__mv) the files to the directory. Once you have done this, you can list them in the files section of the rpm
An idea I've just had is to place them in a different directory and use the %pre section to copy them across to %{_libdir}.
That's not the right way to do it!
I think that the problem is misunderstood, bacula builds with either mysql, postgresql or sqlite support and the built libraries all have the same names but support the three different databases. So at the end of the %build process I have three sets of libraries to be installed in _libdir for bacula-mysql, bacula-postgresql and bacula-sqlite rpms and the last ones to be installed will overwrite the others. If there isn't a way to get osc to build with three different spec files then short of installing them in _libdir/bacula-mysql/, _libdir/bacula-posgresql/ and _libdir/bacula-sqlite/ and then moving them to _libdir in the %pre or %post section of the three different rpms then they have to be built in three different project packages. I once saw a package in build service with two spec files but I can't remember which one it was and whether more than one was used in the package build. Regards Dave P
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 12/20/2009 06:52 PM, Schlomo Schapiro wrote:
Hi,
did you talk to Kern about modifying Bacula so that it builds these libraries into different names and dynamically loads the correct one? This would allow the user to actually have the DB backend as a configuration option.
This could be as primitive as putting the various libraries into different subdirs of _libdir/bacula and adding the correct dir to LD_LIBRARY_PATH of the start script.
IMHO any solution you make here should go upstream...
An alternative is the use of update-alternatives as mentioned already in this thread.
Any "hacking solution" as part of the RPMs or SPEC files is likely to produce much more management overhead for you as the maintainer. You could for example build different subpackages that exclude each other. But then the user would be confronted at installation time to choose the correct database, not so intuitive to the average user as a configuration option.
Bottom line is, either Bacula solves this problem or you will have a lot of pain maintaining the RPMs. BTW, are you the author of the RPMs on http://www.bacula.org/en/?page=downloads? If not, maybe you look at the src.rpm that can be found there and how it builds the different DB backend RPMs... And of course you might merge your work back into the "official" Bacula SPEC file...
Regards, Schlomo
I based my original build on the spec file from upstream's source rpm and then adapted it for opensuse because their %post scripts don't work for suse and don't pass build service rpmlint test. I have a mysql package in Contrib but it seems there is a demand for postgresql and when I closed the bug for no x86_64 rpms for bacula, sqlite was also requested. You speak with great wisdom, if it's easy for upstream to combine the database support it will make life a lot easier for me in the long run. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi Schlomo Schapiro schrieb:
Hi,
did you talk to Kern about modifying Bacula so that it builds these libraries into different names and dynamically loads the correct one? This would allow the user to actually have the DB backend as a configuration option.
I did, with following result: Hello, This is a project that I (and we) have wanted and planned for quite some time, and in fact, it is now an "official" project being actively worked on by Marco and will shortly be documented on our development blog. Due to scheduling, this feature will not make it into the 3.2.0 release (due by end of Jan 2010), but will almost surely (99%) be in the release after that. Thanks for the suggestion. I probably will not add it to the project file, but do not worry, because it is well on track to be implemented already. Best regards, Kern On Sunday 22 November 2009 12:25:50 Christian wrote:
Item ?: Shared object for catalog
Date: 21 November 2009
Origin: Christian Wittmer. chris@computersalat.de
Status: New request
What: Provide shared object for catalog when building with different SQL engines.
Why: You can build --with-postgresql --with-sqlite --with-mysql at the same time and decide later which db-backend to choose and not before building bacula.
It would make building RPM much more easier. You just can provide a subpackage with the shared object, e.g. bacula-mysql, bacula-pgsql, bacula-sqlite
--------------------------------------------------------------------------- --- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 20/12/09 02:20, Dave Plater wrote:
I need to produce two rpms from the same package bacula, one built with -with-postgresql and one -with-mysql, in fact there is an sqlite version as well but if I can make two then I can make three. The resulting libraries have the same names but I think the three binaries are identical.
In that case, create two different spec files with the same source and make them to conflict with each other. Unfortunately rpm doesn't support normal commands like cp in
the %files section
huh ? that would be pretty wrong..
An idea I've just had is to place them in a different directory and use the %pre section to copy them across to %{_libdir}.
No.. You are going to mess the target system up. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
I have thought of another possible way of temporarily solving the problem of three flavors of bacula but don't want to tread on any toes. I can specify different --libexecdir. --libdir and --sbindir for each package with wrappers in /sbin to run the actual binaries (haven't tried this yet). This is a workaround until a bacula is released that is configurable for all the databases or I can help upstream to produce opensuse compliant rpms. Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 21/12/09 06:35, Dave Plater wrote:
I have thought of another possible way of temporarily solving the problem of three flavors of bacula but don't want to tread on any toes. I can specify different --libexecdir. --libdir and --sbindir for each package with wrappers in /sbin to run the actual binaries (haven't tried this yet).
That looks even worst... try two spec file that conflict with each other. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 12/21/2009 01:54 PM, Cristian Rodríguez wrote:
On 21/12/09 06:35, Dave Plater wrote:
I have thought of another possible way of temporarily solving the problem of three flavors of bacula but don't want to tread on any toes. I can specify different --libexecdir. --libdir and --sbindir for each package with wrappers in /sbin to run the actual binaries (haven't tried this yet).
That looks even worst... try two spec file that conflict with each other.
Is there a way to use two spec files in one package? I tried that first and only the one matching the package name was built. Of course I make the rpms conflict. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Mon, Dec 21, 2009 at 04:16:45PM +0200, Dave Plater wrote:
On 12/21/2009 01:54 PM, Cristian Rodríguez wrote:
On 21/12/09 06:35, Dave Plater wrote:
I have thought of another possible way of temporarily solving the problem of three flavors of bacula but don't want to tread on any toes. I can specify different --libexecdir. --libdir and --sbindir for each package with wrappers in /sbin to run the actual binaries (haven't tried this yet).
That looks even worst... try two spec file that conflict with each other.
Is there a way to use two spec files in one package? I tried that first and only the one matching the package name was built. Of course I make the rpms conflict.
Nothing is btw stopping you from building from the same sources several times (with out-of-tree build directory) or perhaps doing some plugin magic. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Montag, 21. Dezember 2009 15:16:45 schrieb Dave Plater:
On 12/21/2009 01:54 PM, Cristian Rodríguez wrote:
On 21/12/09 06:35, Dave Plater wrote:
I have thought of another possible way of temporarily solving the problem of three flavors of bacula but don't want to tread on any toes. I can specify different --libexecdir. --libdir and --sbindir for each package with wrappers in /sbin to run the actual binaries (haven't tried this yet).
That looks even worst... try two spec file that conflict with each other.
Is there a way to use two spec files in one package? I tried that first and only the one matching the package name was built. Of course I make the rpms conflict.
You can host them in one package, but you need to create once a source link from the other package space. You don't need to touch that one ever, but it is required (to have to build spaces, one for each build). -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Monday 21 December 2009 15:16:45 Dave Plater wrote:
On 12/21/2009 01:54 PM, Cristian Rodríguez wrote:
On 21/12/09 06:35, Dave Plater wrote:
I have thought of another possible way of temporarily solving the problem of three flavors of bacula but don't want to tread on any toes. I can specify different --libexecdir. --libdir and --sbindir for each package with wrappers in /sbin to run the actual binaries (haven't tried this yet).
That looks even worst... try two spec file that conflict with each other.
Is there a way to use two spec files in one package? I tried that first and only the one matching the package name was built. Of course I make the rpms conflict.
Have a look at the gcc44 or libqt4 packages - those are two examples that have multiple spec files. For libqt4: You have libqt4 package and a source link to libqt4-sql-plugins and obs uses just the $package.spec file, Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On 12/21/2009 05:25 PM, Andreas Jaeger wrote:
On Monday 21 December 2009 15:16:45 Dave Plater wrote:
On 12/21/2009 01:54 PM, Cristian Rodríguez wrote:
On 21/12/09 06:35, Dave Plater wrote:
I have thought of another possible way of temporarily solving the problem of three flavors of bacula but don't want to tread on any toes. I can specify different --libexecdir. --libdir and --sbindir for each package with wrappers in /sbin to run the actual binaries (haven't tried this yet).
That looks even worst... try two spec file that conflict with each other.
Is there a way to use two spec files in one package? I tried that first and only the one matching the package name was built. Of course I make the rpms conflict.
Have a look at the gcc44 or libqt4 packages - those are two examples that have multiple spec files.
For libqt4: You have libqt4 package and a source link to libqt4-sql-plugins and obs uses just the $package.spec file,
Andreas
Ok I'm stuck, how do I create the source link? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 12/22/2009 01:32 PM, Cristian Rodríguez wrote:
On 22/12/09 08:20, Dave Plater wrote:
Ok I'm stuck, how do I create the source link?
Using osc linkpac.
So I must create a subproject with the three different packages and use linkpac to combine them in the main package? Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Dienstag, 22. Dezember 2009 15:34:42 schrieb Dave Plater:
On 12/22/2009 01:32 PM, Cristian Rodríguez wrote:
On 22/12/09 08:20, Dave Plater wrote:
Ok I'm stuck, how do I create the source link?
Using osc linkpac.
So I must create a subproject with the three different packages and use linkpac to combine them in the main package?
You can do this in one project. If you have Project X and package Y, with Y.spec and Z.spec, just call osc linkpac X Y X Z obviously easy ;) bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 12/22/2009 04:39 PM, Adrian Schröter wrote:
Am Dienstag, 22. Dezember 2009 15:34:42 schrieb Dave Plater:
On 12/22/2009 01:32 PM, Cristian Rodríguez wrote:
On 22/12/09 08:20, Dave Plater wrote:
Ok I'm stuck, how do I create the source link?
Using osc linkpac.
So I must create a subproject with the three different packages and use linkpac to combine them in the main package?
You can do this in one project.
If you have Project X and package Y, with Y.spec and Z.spec, just call
osc linkpac X Y X Z
obviously easy ;)
bye adrian
I have bacula.spec and baculapostgre.spec in home:plater:branches:openSUSE:Factory:Contrib bacula I execute:- osc linkpac home:plater:branches:openSUSE:Factory:Contrib bacula home:plater:branches:openSUSE:Factory:Contrib baculapostgre and I end up with a baculapostgre package which is just a link in the same project but the postgre rpms are in the baculapostgre package and the mysql ones are in bacula. I want to have all the rpms in the bacula package, similar to the libqt4 package. Have I perhaps done something wrong? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 22/12/09 14:00, Dave Plater wrote: and I end up
with a baculapostgre package which is just a link in the same project but the postgre rpms are in the baculapostgre package and the mysql ones are in bacula.
That's right, assuming you have spec files named baculapostgre.spec and bacula.spec I want to have all the rpms in the bacula package. You can't.
Have I perhaps done something wrong?
No, it is just fine. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 12/22/2009 07:11 PM, Cristian Rodríguez wrote:
On 22/12/09 14:00, Dave Plater wrote: and I end up
with a baculapostgre package which is just a link in the same project but the postgre rpms are in the baculapostgre package and the mysql ones are in bacula.
That's right, assuming you have spec files named baculapostgre.spec and bacula.spec
I want to have all the rpms in the bacula package.
You can't.
Have I perhaps done something wrong?
No, it is just fine.
How does libqt4 get it right? It has three spec files libqt4, libqt4-sql-plugins and libqt4-doc and all of the rpms from these spec files are built in the one package. This is much cleaner than having three different packages all using the same source and also better than using update-alternatives in the %pre section of the rpm. Meanwhile Contrib only has the mysql version of bacula. Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 22/12/09 14:48, Dave Plater wrote:
How does libqt4 get it right? It has three spec files libqt4, libqt4-sql-plugins and libqt4-doc and all of the rpms from these spec files are built in the one package.
libqt4-sql-plugins is a link to libqt4 package, exactly like you are doing it. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 12/22/2009 08:14 PM, Cristian Rodríguez wrote:
On 22/12/09 14:48, Dave Plater wrote:
How does libqt4 get it right? It has three spec files libqt4, libqt4-sql-plugins and libqt4-doc and all of the rpms from these spec files are built in the one package.
libqt4-sql-plugins is a link to libqt4 package, exactly like you are doing it.
No I think what I want is not possible, I want the three spec files to build in the same package. With the link the linked package gets updated when the main package changes but the rpms are built in the package with the same name as the spec file. It would be a nice feature if build service supported this. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wednesday 23 December 2009 16:34:49 Dave Plater wrote:
No I think what I want is not possible, I want the three spec files to build in the same package. With the link the linked package gets updated when the main package changes but the rpms are built in the package with the same name as the spec file. It would be a nice feature if build service supported this.
Why do you need it? All packages will end in the same repository since you use the same project. Isn't that enough? Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On 12/23/2009 05:39 PM, Andreas Jaeger wrote:
On Wednesday 23 December 2009 16:34:49 Dave Plater wrote:
No I think what I want is not possible, I want the three spec files to build in the same package. With the link the linked package gets updated when the main package changes but the rpms are built in the package with the same name as the spec file. It would be a nice feature if build service supported this.
Why do you need it? All packages will end in the same repository since you use the same project. Isn't that enough?
Andreas
ATM bacula can only be built for a specific database, the version in contrib is the mysql version, people are asking for postgresql, which my co-maintainer uses, and the sqlite version. The binaries produced by each build have the same names so this equals either two new packages besides the existing one or the use of update alternatives in the %pre sections of the spec file like vim. When bacula is released early next year with a configurable data base backend only one package and spec file will be needed. If multiple spec files worked in one package this wouldn't be a problem at all. Three seperate packages = three times as many hermes messages, three times as many working copies. Ok I concede that linking the other two to one helps decrease the amount of maintainance but the only difference between the three spec files are the package name and the line --with-mysql substituted with --with-postgresql substituted with --with-sqlite. I'm not complaining, I'll just carry on and get the job done in the best way I can. All I said was, it would be a nice feature if multiple spec builds were possible. I'm an unpaid community member who maintains three packages besides bacula and multiple spec builds in one package would make my life easier and maybe a few other people's. Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, on Mittwoch, 23. Dezember 2009, Dave Plater wrote:
Three seperate packages = three times as many hermes messages, three times as many working copies. Ok I concede that linking the other two to one helps decrease the amount of maintainance but the only difference between the three spec files are the package name and the line --with-mysql substituted with --with-postgresql substituted with --with-sqlite.
In this case you don't even need multiple spec files - you just need some %if in your specfile. There's a less-known and very underdocumented feature in link files: <topadd>. I had to search for it in the mailinglist archives (it's very well hidden if you don't remember its name), therefore I added it to the wiki to have at least some documentation about it: http://en.opensuse.org/Build_Service/Tips_and_Tricks#Adding_a_line_at_the_to... You'll still need three separate packages (two of them only consisting of a _link file), but that's how the buildservice works ;-) Regards, Christian Boltz --
Genau. [aus dem CVS] Killen. Du darfst... (oder geht das mit LinCVS etwa nicht? ;-) Hohn und Spott perlen an mir ab. Ich hab es gelöscht. Was? LinCVS? [> Ratti und Christian Boltz in fontlinge-devel] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Christian, Op vrijdag 25 december 2009 01:21:07 schreef Christian Boltz:
There's a less-known and very underdocumented feature in link files: <topadd>. I had to search for it in the mailinglist archives (it's very well hidden if you don't remember its name), therefore I added it to the wiki to have at least some documentation about it:
http://en.opensuse.org/Build_Service/Tips_and_Tricks#Adding_a_line_at_the_t op_of_the_spec_file
thanks for this useful tip. I changed the information at the above mentioned link slightly, hopefully it is now easier to understand. -- Richard -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wednesday 23 December 2009 19:22:56 Dave Plater wrote:
On 12/23/2009 05:39 PM, Andreas Jaeger wrote:
On Wednesday 23 December 2009 16:34:49 Dave Plater wrote:
No I think what I want is not possible, I want the three spec files to build in the same package. With the link the linked package gets updated when the main package changes but the rpms are built in the package with the same name as the spec file. It would be a nice feature if build service supported this.
Why do you need it? All packages will end in the same repository since you use the same project. Isn't that enough?
Andreas
ATM bacula can only be built for a specific database, the version in contrib is the mysql version, people are asking for postgresql, which my co-maintainer uses, and the sqlite version. The binaries produced by each build have the same names so this equals either two new packages besides the existing one or the use of update alternatives in the %pre sections of the spec file like vim. When bacula is released early next year with a configurable data base backend only one package and spec file will be needed. If multiple spec files worked in one package this wouldn't be a problem at all. Three seperate packages = three times as many hermes messages, three times as many working copies. Ok I concede that linking the other two to one helps decrease the amount of maintainance but the only difference between the three spec files are the package name and the line --with-mysql substituted with --with-postgresql substituted with --with-sqlite.
Why working copies three times? Just use the master of the links and have a script that generates - like it's done for gcc and libqt4 (pre_checkin.sh) from one version the other spec files and the changes file. Then you work on the one version and just update that one, run pre_checkin.sh at the end - and the others get rebuild automatically.
I'm not complaining, I'll just carry on and get the job done in the best way I can. All I said was, it would be a nice feature if multiple spec builds were possible.
You're not the first to hit this problem and we have invented some solutions for these already as described. Please help us documenting this better - and then let's see what can be done to make it easier using, Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Am Mittwoch, 23. Dezember 2009 16:34:49 schrieb Dave Plater:
On 12/22/2009 08:14 PM, Cristian Rodríguez wrote:
On 22/12/09 14:48, Dave Plater wrote:
How does libqt4 get it right? It has three spec files libqt4, libqt4-sql-plugins and libqt4-doc and all of the rpms from these spec files are built in the one package.
libqt4-sql-plugins is a link to libqt4 package, exactly like you are doing it.
No I think what I want is not possible, I want the three spec files to build in the same package. With the link the linked package gets updated when the main package changes but the rpms are built in the package with the same name as the spec file. It would be a nice feature if build service supported this.
That won't work with the current design, we want to have different spec files in a package but selective build them. Also each package has only one build log/history/dependencies/... so you would always need to specify a subpackage for each package. We definitive do not want this. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 12/24/2009 10:11 AM, Adrian Schröter wrote:
Am Mittwoch, 23. Dezember 2009 16:34:49 schrieb Dave Plater:
On 12/22/2009 08:14 PM, Cristian Rodríguez wrote:
On 22/12/09 14:48, Dave Plater wrote:
How does libqt4 get it right? It has three spec files libqt4, libqt4-sql-plugins and libqt4-doc and all of the rpms from these spec files are built in the one package.
libqt4-sql-plugins is a link to libqt4 package, exactly like you are doing it.
No I think what I want is not possible, I want the three spec files to build in the same package. With the link the linked package gets updated when the main package changes but the rpms are built in the package with the same name as the spec file. It would be a nice feature if build service supported this.
That won't work with the current design, we want to have different spec files in a package but selective build them. Also each package has only one build log/history/dependencies/... so you would always need to specify a subpackage for each package.
We definitive do not want this.
bye adrian
Instead I should create a feature request with rpm for a %files section that enables subpackage files to be renamed or something. I've resigned myself to using update-alternatives or different linked packages but at least I've learned a lot about rpm, rpmbuild and packaging in the process. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 24/12/09 05:27, Dave Plater wrote:
Instead I should create a feature request with rpm for a %files section that enables subpackage files to be renamed or something.
No, if something is renamed, it must be done in the %install section. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 12/24/2009 01:27 PM, Cristian Rodríguez wrote:
On 24/12/09 05:27, Dave Plater wrote:
Instead I should create a feature request with rpm for a %files section that enables subpackage files to be renamed or something.
No, if something is renamed, it must be done in the %install section.
I tried the "with --program-suffix or --program-transform-name" you suggested at the beginning of this thread with no success and if I can get it to work and the files build with different names the problem is solved. I know you can't do any shell operations in the %files section, I was suggesting an upstream feature request and I should have added a :-) Merry Christmas and thanks to all for helping to expand my knowledge of packaging. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (11)
-
Adrian Schröter -
Andreas Jaeger -
Christian -
Christian Boltz -
Cristian Rodríguez -
Dave Plater -
Luke Imhoff -
Marcus Meissner -
Philipp Thomas -
Richard Bos -
Schlomo Schapiro