-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Another idea... let's call it "meta" or "virtual" packages...
Make empty packages that pull several dependencies using their Requires tags to make packagers' life
easier.
e.g.
Name: meta-c++-devel
Version: 1.0.0
Release: 1
Requires: make libtool autoconf automake gcc-c++
Requires: libstdc++ libstdc++-devel libgcc glibc-devel
(empty files, empty %setup, empty %build, empty %install)
Note that such a "meta" package should be arch-specific (not "noarch") because it could be that on
some architecture you need different packages than on others (e.g. an x86-optimized assembler would
be included in the "meta-c++-devel" package on x86 and x86_64, but not on ppc or s390).
That way, when packagers need to "BuildRequires" the C++ development environment for another
package, it's just a matter of:
Name: libfoo++
Version: 3.4.5
Release: 39
...
BuildRequires: meta-c++-devel
...
SUSE's y2pmbuild already partly offers that functionality by expanding "virtual" names in
"neededforbuild" to a set of real dependencies, but the issue with that approach is that it works
only when using y2pmbuild.
The solution above would work with any package manager (yast2, smart, yum, apt, ...) and with any
RPM building frontend (rpmbuild, y2pmbuild, abuild, ...), and could even easily "hide" the gory
details of what packages are required on 10.1, 10.0, on 9.3, ... to have a specific environment
(e.g. on SUSE < 9.2, it's "libjpeg" whereas on SUSE >= 9.2 it's "libjpeg libjpeg-devel").
Mauricio "netmask" Teixeira and I talked about that idea, as Mauricio told me that Connectiva has
that approach with so-called "task" packages (task-c++-devel, etc...).
They also use it to do the same as SUSE Linux' "selections" (*.sel files in yast2 repositories),
e.g. "task-mail-server", but that's a different story ;)
I could really use such a "meta-gnome-devel" package ;)))
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
Pascal, Op maandag 19 december 2005 10:19, schreef Pascal Bleser:
Another idea... let's call it "meta" or "virtual" packages...
Make empty packages that pull several dependencies using their Requires tags to make packagers' life easier.
this is nothing new. It has been used in suse-7.3 already. This following packages are virual ones: ./suse/extra/8.1/koffice-suite-3.0-0_rb1.i386.rpm ./suse/extra/7.3/gnome2-2.0-rb2.i386.rpm ./suse/extra/7.3/kde-3.0-3.i386.rpm ./suse/extra/8.2/MPlayer-suite-1.0-rb2.i586.rpm You find them in ftp://ftp.gwdg.de/pub/linux/misc/apt4rpm/
Mauricio "netmask" Teixeira and I talked about that idea, as Mauricio told me that Connectiva has that approach with so-called "task" packages (task-c++-devel, etc...). They also use it to do the same as SUSE Linux' "selections" (*.sel files in yast2 repositories), e.g. "task-mail-server", but that's a different story ;)
I could really use such a "meta-gnome-devel" package ;)))
Than use apt: apt showgroup E: No groupname given. richard@linux:~/cvs/server> man apt Reformatting apt(1), please wait... richard@linux:~/cvs/server> apt groupnames Group name Description ----------- ------------ Basis-Devel-10.0-65.noarch C/C++ Compiler and Tools Fonts-10.0-65.noarch Fonts Games-10.0-65.noarch Games Gnome-10.0-65.noarch GNOME System Gnome-Devel-10.0-65.noarch GNOME Development apt showgroup Gnome-Devel-10.0-65.noarch Group: Gnome-Devel-10.0-65.noarch Summary: GNOME Development Required groups: Gnome Basis-Devel Packages: aalib-devel aalib-devel-32bit alsa-devel anjuta etc man apt is your friend would Patrick say. -- Richard Bos Without a home the journey is endless
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Richard Bos wrote:
Pascal,
Op maandag 19 december 2005 10:19, schreef Pascal Bleser:
Another idea... let's call it "meta" or "virtual" packages...
Make empty packages that pull several dependencies using their Requires tags to make packagers' life easier.
this is nothing new. It has been used in suse-7.3 already. This following packages are virual ones: ./suse/extra/8.1/koffice-suite-3.0-0_rb1.i386.rpm ./suse/extra/7.3/gnome2-2.0-rb2.i386.rpm ./suse/extra/7.3/kde-3.0-3.i386.rpm ./suse/extra/8.2/MPlayer-suite-1.0-rb2.i586.rpm
You find them in ftp://ftp.gwdg.de/pub/linux/misc/apt4rpm/
Sure, I could also just roll my own in my own repository, but the point is to have them in the core distribution. And with any package manager frontend, not only apt. If it's only in one additional repository (and furthermore only with apt), it's not sufficient. If someone wants to rebuild my src.rpm, she won't be able to find that virtual package unless she 1) has and uses apt 2) has configured apt to include that repository IMO src.rpm's should really be "rebuildable" out-of-the-box, not only under certain conditions and requiring to use specific repositories (besides the core distribution or what would be needed for the BuildRequires (e.g. packman)), as well as requiring specific package manager frontends. Same is true for the tools BTW, src.rpm's must be "buildable" just with rpmbuild.
Mauricio "netmask" Teixeira and I talked about that idea, as Mauricio told me that Connectiva has that approach with so-called "task" packages (task-c++-devel, etc...). They also use it to do the same as SUSE Linux' "selections" (*.sel files in yast2 repositories), e.g. "task-mail-server", but that's a different story ;)
I could really use such a "meta-gnome-devel" package ;)))
Than use apt:
apt showgroup ...
Very interesting, but not of any help in this case, because it only works with apt and when you have
that repository configured.
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
* Richard Bos
man apt is your friend would Patrick say.
whoo, meeee <grin> -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
participants (3)
-
Pascal Bleser -
Patrick Shanahan -
Richard Bos