Re: apt-get internals help

2003-09-07 Thread Steve Greenland
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




Re: apt-get internals help

2003-09-06 Thread Matt Zimmerman
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

2003-09-06 Thread George Danchev
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 keyserver.bu.edu
1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 
  
   




Re: apt-get internals help

2003-09-06 Thread Neil Roeth
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

2003-09-06 Thread Steve Kemp
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

2003-09-06 Thread Matt Zimmerman
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

2003-09-06 Thread George Danchev
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 keyserver.bu.edu
1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 
  
   




Re: apt-get internals help

2003-09-06 Thread Matt Zimmerman
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

2003-09-06 Thread Matt Zimmerman
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

2003-09-05 Thread Daniel Burrows
  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




apt-get internals help

2003-09-05 Thread Neil Roeth
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

2003-09-05 Thread Matt Chorman
-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=getsearch=0x7D81740A
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/WUFLZosHVX2BdAoRAvxoAJ9AiiD+6humhJ2K7f34MXjE/g3WXgCePVri
cSCoRPLcLCBjE+n2BZMOiMw=
=CgWB
-END PGP SIGNATURE-




apt-get internals help

2003-09-04 Thread Matt Chorman
-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=getsearch=0x7D81740A
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/WAReZosHVX2BdAoRAnBvAJ9qsGc5TH6puukXVugxmZtkOau78ACghXNG
Dj643Zh6bS/zWNERexMfW6Y=
=2zME
-END PGP SIGNATURE-