apt-get internals help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am currently trying to use apt-get source to compile a few source packages. I would like to pass some custom configure flags to the configure process - i.e. something like conifgure --with-mysql. The dependancies are met, I just need to pass this flag. As far as I can see, apt-get does not have this ability. I can also not find in the source of apt where the system call for configure is.. So my question(s): Am I missing something? Can apt-get pass configure options? If not, could someone who knows point me in the right direction in the source? Thanks! Also, please reply to me and/or cc the list as I am not subscribed. - -- Matt http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D81740A -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/WAReZosHVX2BdAoRAnBvAJ9qsGc5TH6puukXVugxmZtkOau78ACghXNG Dj643Zh6bS/zWNERexMfW6Y= =2zME -END PGP SIGNATURE-
apt-get internals help
On Sep 4, Matt Chorman ([EMAIL PROTECTED]) wrote: > I am currently trying to use apt-get source to compile a few source > packages. > I would like to pass some custom configure flags to the configure process - > i.e. something like conifgure --with-mysql. The dependancies are met, I just > need to pass this flag. As far as I can see, apt-get does not have this > ability. I can also not find in the source of apt where the system call for > configure is.. So my question(s): > > Am I missing something? Can apt-get pass configure options? > > If not, could someone who knows point me in the right direction in the > source? You need to look in the package itself for the call to configure, not in the apt source. Suppose you are attempting to download and compile foo_1.2.3-4. apt-get source foo # no "--compile" option cd foo-1.2.3 vi debian/rules # find the call to configure, add "--with-mysql" fakeroot dpkg-buildpackage -uc -us This will result in a .deb in the directory from which you called apt-get source, which you can install with dpkg. -- Neil Roeth
Re: apt-get internals help
See debian/rules. You might also want to look at http://www.debian.org/doc/debian-policy/ch-source.html, especially http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules . [there should be better documentation, but I'm not sure what it would be] Daniel
Re: apt-get internals help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 05 September 2003 06:04 pm, Neil Roeth wrote: > You need to look in the package itself for the call to configure, not in > the apt source. Suppose you are attempting to download and compile > foo_1.2.3-4. > > apt-get source foo# no "--compile" option > cd foo-1.2.3 > vi debian/rules # find the call to configure, add "--with-mysql" > fakeroot dpkg-buildpackage -uc -us > > This will result in a .deb in the directory from which you called apt-get > source, which you can install with dpkg. Ouch.. The reason I am asking is I am working with some people who are trying to enhance apt-build (www.debtoo.org).. I am in the process of writing some scripts that add "gentoo" like USE flag functionality - you can add "mysql" to the flags and on any package that has this functionality it will add - --enable-mysql or --with-mysql (or whatever is appropriate.) I know there will be the problem of dependancies.. Regardless, at this point I have a functioning script that will take a package name and determine the possible optional flags that can be passed to configure. I've taken a look at the files and I understand the source configuration process better. What I think this adds up to is, basically, is that my script is going to have to hack debian/rules on each package? There is no other way to pass optional configure flags to a compile? Thanks for any help you or pointers you can give me on this - -- Matt http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D81740A -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/WUFLZosHVX2BdAoRAvxoAJ9AiiD+6humhJ2K7f34MXjE/g3WXgCePVri cSCoRPLcLCBjE+n2BZMOiMw= =CgWB -END PGP SIGNATURE-
Re: apt-get internals help
On Fri, Sep 05, 2003 at 07:07:03PM -0700, Matt Chorman wrote: > I've taken a look at the files and I understand the source configuration > process better. What I think this adds up to is, basically, is that my script > is going to have to hack debian/rules on each package? There is no other way > to pass optional configure flags to a compile? You cannot hope to write a script smart enough to modify an arbitrary debian/rules to do what you want. What you need to do is to come up with a useful standard for passing this kind of option to debian/rules, and modify packages to support it. Sound like a waste of time? I agree. -- - mdz
Re: apt-get internals help
On Saturday 06 September 2003 07:34, Matt Zimmerman wrote: > On Fri, Sep 05, 2003 at 07:07:03PM -0700, Matt Chorman wrote: > > I've taken a look at the files and I understand the source configuration > > process better. What I think this adds up to is, basically, is that my > > script is going to have to hack debian/rules on each package? There is no > > other way to pass optional configure flags to a compile? how do you manipulate the rules files? What do you look for inside, what do you add or replace ? > You cannot hope to write a script smart enough to modify an arbitrary > debian/rules to do what you want. What you need to do is to come up with a > useful standard for passing this kind of option to debian/rules, and modify > packages to support it. It might be easier if more debian/rules files respect DEB_BUILD_OPTIONS. I'm not sure what the policies say about that, but could that be a standard ? > Sound like a waste of time? I agree. it might be like sort of waste of time, but this is what external projects are for.. future will prove if this effort deserves to live ;-). Presently it is not a debian's BTS job to track bugs for locally rebuilt packages with arbitrary flags or optimizations... But that's for the time being, who knows what the future brings. Perhaps we will have BTS hanling debian's source package bugs ... -- pub 4096R/0E4BD0AB 2003-03-18 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Re: apt-get internals help
On Sep 5, Matt Chorman ([EMAIL PROTECTED]) wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Friday 05 September 2003 06:04 pm, Neil Roeth wrote: > > You need to look in the package itself for the call to configure, not in > > the apt source. Suppose you are attempting to download and compile > > foo_1.2.3-4. > > > > apt-get source foo # no "--compile" option > > cd foo-1.2.3 > > vi debian/rules# find the call to configure, add "--with-mysql" > > fakeroot dpkg-buildpackage -uc -us > > > > This will result in a .deb in the directory from which you called apt-get > > source, which you can install with dpkg. > > Ouch.. The reason I am asking is I am working with some people who are > trying > to enhance apt-build (www.debtoo.org).. I am in the process of writing some > scripts that add "gentoo" like USE flag functionality - you can add "mysql" > to the flags and on any package that has this functionality it will add > - --enable-mysql or --with-mysql (or whatever is appropriate.) > > I know there will be the problem of dependancies.. Regardless, at this point > I > have a functioning script that will take a package name and determine the > possible optional flags that can be passed to configure. > > I've taken a look at the files and I understand the source configuration > process better. What I think this adds up to is, basically, is that my > script > is going to have to hack debian/rules on each package? There is no other way > to pass optional configure flags to a compile? > > Thanks for any help you or pointers you can give me on this I did not realize the full context of what you were trying to do from your initial question. You're proposing a fundamental change from a process that is static and noninteractive (so that build daemons will work, package building is reproducible, etc.) to a process that is dynamic and interactive (so users can custom build packages for their environment). It seems you were hoping to tweak a few scripts and be done, but it will take more than that. I think you need to step back and think it through more deeply. Good luck! -- Neil Roeth
Re: apt-get internals help
On Sat, Sep 06, 2003 at 09:50:14AM -0400, Neil Roeth wrote: > I did not realize the full context of what you were trying to do from your > initial question. You're proposing a fundamental change from a process that is > static and noninteractive (so that build daemons will work, package building > is reproducible, etc.) to a process that is dynamic and interactive (so users > can custom build packages for their environment). It seems you were hoping to > tweak a few scripts and be done, but it will take more than that. I think you > need to step back and think it through more deeply. If they are global defaults, a la Gentoo, perhaps a small shell script would do the job: #!/bin/sh # # ~/bin/gcc - Give GCC global flags # /usr/bin/gcc `cat /etc/gcc-options.default` "$*" Obviously that's just a bare idea, a more complete solution would have to look out for conflicting arguments, and work with G++ etc. That would give you the oppertunity to specify global flags for GCC for all your builds. Steve -- pgppLwbHf5Jw1.pgp Description: PGP signature
Re: apt-get internals help
On Sat, Sep 06, 2003 at 11:40:34AM +0300, George Danchev wrote: > On Saturday 06 September 2003 07:34, Matt Zimmerman wrote: > > You cannot hope to write a script smart enough to modify an arbitrary > > debian/rules to do what you want. What you need to do is to come up with a > > useful standard for passing this kind of option to debian/rules, and modify > > packages to support it. > > It might be easier if more debian/rules files respect DEB_BUILD_OPTIONS. > I'm not sure what the policies say about that, but could that be a standard ? DEB_BUILD_OPTIONS is for generic options which apply to almost any package. What you want are package-specific options, like enabling or disabling features. An environment variable would be a reasonable way to implement it, but I think it should be separate from DEB_BUILD_OPTIONS. -- - mdz
Re: apt-get internals help
On Saturday 06 September 2003 19:34, Matt Zimmerman wrote: > On Sat, Sep 06, 2003 at 11:40:34AM +0300, George Danchev wrote: > > On Saturday 06 September 2003 07:34, Matt Zimmerman wrote: > > > You cannot hope to write a script smart enough to modify an arbitrary > > > debian/rules to do what you want. What you need to do is to come up > > > with a useful standard for passing this kind of option to debian/rules, > > > and modify packages to support it. > > > > It might be easier if more debian/rules files respect DEB_BUILD_OPTIONS. > > I'm not sure what the policies say about that, but could that be a > > standard ? > > DEB_BUILD_OPTIONS is for generic options which apply to almost any package. > What you want are package-specific options, like enabling or disabling > features. An environment variable would be a reasonable way to implement > it, but I think it should be separate from DEB_BUILD_OPTIONS. I do not think the variable is the real issue here. If we grab a snippet of the MPlayer's debian/rules: ./configure --prefix=/usr --confdir=/etc/mplayer $(DEB_BUILD_OPTIONS) --prefix and --confdir are generic and they come with the generic unmodified rules file. The real issue here is that we need an separate (new or additional) media to store the so called USE options per source package, where the maintainer can store the optional flags he decided could be useful for that version of the source package - let's say debian/use. Then utilities like apt-build could be hacked to loop over this file first and to show us a nice a la "debconf with many faces interface" like: This are the alternatives to build this Debian source package: [ ]--with-apples (recommended and used by buildd) [ ]--with-raspberries [ x ]--with-apples --with-raspberries Then apt-build resets the DEB_BUILD_OPTIONS per this session like: # DEB_BUILD_OPTIONS="\ --with-apples --with-raspberries \ $ANY-OTHERS-COMMON-OPTIONS-IF-ANY" \ fakeroot debian/rules binary -- pub 4096R/0E4BD0AB 2003-03-18 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Re: apt-get internals help
On Sat, Sep 06, 2003 at 08:28:58PM +0300, George Danchev wrote: > I do not think the variable is the real issue here. If we grab a snippet of > the MPlayer's debian/rules: > ./configure --prefix=/usr --confdir=/etc/mplayer $(DEB_BUILD_OPTIONS) That's a bug. What happens when DEB_BUILD_OPTIONS=nostrip or DEB_BUILD_OPTIONS=noopt, which are actually specified in the policy manual as valid? configure will try to interpret that as an architecture name, and the build will fail. > --prefix and --confdir are generic and they come with the generic unmodified > rules file. The real issue here is that we need an separate (new or > additional) media to store the so called USE options per source package, > where the maintainer can store the optional flags he decided could be useful > for that version of the source package - let's say debian/use. Then utilities > like apt-build could be hacked to loop over this file first and to show us a > nice a la "debconf with many faces interface" like: Which is exactly what I recommended in my previous message. > This are the alternatives to build this Debian source package: > [ ]--with-apples (recommended and used by buildd) > [ ]--with-raspberries > [ x ]--with-apples --with-raspberries > > Then apt-build resets the DEB_BUILD_OPTIONS per this session like: > # DEB_BUILD_OPTIONS="\ > --with-apples --with-raspberries \ > $ANY-OTHERS-COMMON-OPTIONS-IF-ANY" \ > fakeroot debian/rules binary ...just before I said that DEB_BUILD_OPTIONS was _not the right place for it_, because it's already documented, with a completely different purpose which is incompatible with your proposition. -- - mdz
Re: apt-get internals help
On Sat, Sep 06, 2003 at 03:54:18PM +0100, Steve Kemp wrote: > If they are global defaults, a la Gentoo, perhaps a small shell script > would do the job: > > #!/bin/sh > # > # ~/bin/gcc - Give GCC global flags > # > /usr/bin/gcc `cat /etc/gcc-options.default` "$*" > > Obviously that's just a bare idea, a more complete solution would have > to look out for conflicting arguments, and work with G++ etc. > > That would give you the oppertunity to specify global flags for GCC > for all your builds. If the idea were to support different compiler flags (which was not how I interpreted what has been said so far), then I think the most sensible thing would be simply to say that packages should honor the CFLAGS and CXXFLAGS variables set in the build environment. -- - mdz
Re: apt-get internals help
On 06-Sep-03, 12:28 (CDT), George Danchev <[EMAIL PROTECTED]> wrote: > I do not think the variable is the real issue here. If we grab a snippet of > the MPlayer's debian/rules: > ./configure --prefix=/usr --confdir=/etc/mplayer $(DEB_BUILD_OPTIONS) That's a bug, as Matt noted. > --prefix and --confdir are generic Really? Not for this package: ~/packages/cron/debian$ grep prefix rules ~/packages/cron/debian$ Despite the attempts of the evil autotools people, autoconf is NOT required to build portable software, and many enlightened developers avoid it, along with the Satanic automake and the unspeakably foul libtool. (Actually, vixie-cron probably pre-dates autoconf, but my point is still valid: --prefix is NOT generically used in debian/rules.) Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
