Re: Source dependencies: are we ready?
At 14:42 +0200 1999-10-27, Santiago Vila wrote: On Wed, 27 Oct 1999, Antti-Juhani Kaijanaho wrote: On Wed, Oct 27, 1999 at 03:50:06AM -0700, Seth R Arnold wrote: ldso ? Do you need this to compile a Hello World? I doubt gcc works without ldso ;-) Sure it does, it's not a libc5 executable. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Source dependencies: are we ready?
On Wed, 27 Oct 1999, Joel Klecker wrote: At 14:42 +0200 1999-10-27, Santiago Vila wrote: I doubt gcc works without ldso ;-) Sure it does, it's not a libc5 executable. Ooops! I forgot that libc6 uses its own dynamic linker. Why is ldso still essential, then? Maybe it should be just required in potato, and its extended description should be changed so that it does no longer read It is required by any program that uses shared libraries.. Thanks. -- b303ad623fdaffaed997eb8c60f627a2 (a truly random sig)
Re: Source dependencies: are we ready?
At 11:42 +0200 1999-10-28, Santiago Vila wrote: On Wed, 27 Oct 1999, Joel Klecker wrote: At 14:42 +0200 1999-10-27, Santiago Vila wrote: I doubt gcc works without ldso ;-) Sure it does, it's not a libc5 executable. Ooops! I forgot that libc6 uses its own dynamic linker. Why is ldso still essential, then? ldconfig -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Source dependencies: are we ready?
Previously Marcus Brinkmann wrote: I agree with Ben that dpkg-source should not care about build dependencies (hey, it only unpacks the source, I only need ar and tar and gzip for this!) You two seem to overlook that with dpkg-source I mean the packagename here, not the script dpkg-source. Klee named the package dpkg-source between it implemenets everything needed to manage sources for a Debian package. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgpNghXYYnR9r.pgp Description: PGP signature
Re: Source dependencies: are we ready?
On Wed, Oct 27, 1999 at 12:14:05AM +0200, Marcus Brinkmann wrote: On Tue, Oct 26, 1999 at 03:46:23PM -0400, Ben Collins wrote: Sbuild calls dpkg-source to unpack, what does it have to do with the source format?! All it has to do is call whatever executable is needed for the unpacking. It _already_ handles _everything_ else, _and_ the Build Dependencies. My suggestion is to keep the enforcement of build deps out of raw tools like dpkg-source and dpkg-buildpackage and in specialized tools like sbuild (which already has it) and apt (which already builds and downloads packages, so it can handle checking build deps with modifications). I agree with Ben that dpkg-source should not care about build dependencies (hey, it only unpacks the source, I only need ar and tar and gzip for this!) dpkg-buildpackage should optionally verify the build dependencies only. apt should have an option to fulfill source depends for a set of packages. sbuild is overkill for most people. Also, it is tightly related to the wanna build autobuilder. It is pretty much hackish, and I would rather see something replacing sbuild than vice versa. sbuild can be downplayed for what we need in general (leave the current sbuild to the autobuilders). The thing is, it's features are nice and it works well, we just need to strip it down for general use. Ben
Re: Source dependencies: are we ready?
b) supports multiple patches That's a nice goal, but has nothing to do with source-dependencies... c) can setup a buildroot and start building everything that is needed to build a package Ouch... Do you want to build glibc before building any package? And build all src-deps of glibc transitively (this includes gcc, bzip2, tetex-bin, ...) ?? Roman
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 04:51:23PM +0200, Wichert Akkerman wrote: Previously Antti-Juhani Kaijanaho wrote: How do you define complete implementation? A dpkg-source that: a) supports build-dependencies b) supports multiple patches c) can setup a buildroot and start building everything that is needed to build a package Right now c) doesn't seem to work correctly on Linux systems, otherwise it seems to work fine. I had a look at Klee's sources. They're poorly documented and they do too much to be relevant to this policy amendment. But the ideas are interesting, so I'll see if I can figure the sources out and do something about them ;-) Is it orphaned by Klee, ie. are we looking for a new upstream developer or...? IMHO you should not delay adding the patch to dpkg-dev. Klee's source format is not relevant to this amendment. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
I still think sbuild is the way to go. I still think sbuild is not the way to go and would rather see sbuild modified to handle the new source format. sbuild will automatically use a new source format as soon as dpkg-source knows it :-) Actually, sbuild is just a (rather blown-up :-) wrapper around dpkg-source and dpkg-buildpackage. It's main task are source dependencies, of course. However, it also does a lot of minor, but nevertheless useful things (most for batch building): getting sources from multiple locations (local or FTP), keeping log files, timeouts, store built packages that are src-deps for later builds, statistics, patches, ... For my part, I wouldn't mind if dpkg-buildpackage would check src-deps, but there should be an option to skip this. sbuild already has checked src-deps, so this would be double work. My personal view of sbuild is that it's a tool for mass builds. If Debian wants to adopt it as replacement for dpkg-buildpackage, please go ahead, I won't mind :-) But it was written with a different intention. Roman
Re: Source dependencies: are we ready?
At 11:34 +0200 1999-10-27, Roman Hodek wrote: c) can setup a buildroot and start building everything that is needed to build a package Ouch... Do you want to build glibc before building any package? And build all src-deps of glibc transitively (this includes gcc, bzip2, tetex-bin, ...) ?? He means have that as an ability, but I don't see that as relevant to what we *need* for source depends to be useful. As an aside, I don't think the present dpkg-buildpackage is a suitable platform for dependency checking, being that it's only a shell script. I've eliminated the tetex-bin dependency, BTW. bzip2 hadn't occurred to me as a dependency, but I guess it is. What else? patch? We need to discuss what's build-essential anyway. Here's a start: libc-dev gcc g++ libstdc++-dev patch make dpkg-dev binutils bison -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Source dependencies: are we ready?
On Wed, Oct 27, 1999 at 03:41:00AM -0700, Joel Klecker wrote: [...] I've eliminated the tetex-bin dependency, BTW. bzip2 hadn't occurred to me as a dependency, but I guess it is. What else? patch? We need to discuss what's build-essential anyway. Here's a start: libc-dev gcc g++ libstdc++-dev patch make dpkg-dev binutils bison autoconf ? bin86 ? ldso ? supporting stuff tar ? cpio ? gzip ? bzip2 ? find ? perl ? less likely, but still possible... curses ? groff/man ? specialized... perl ? wish ? python ? jdk ? (some of the items under 'supporting stuff' I found in the linux kernel Makefile.. :) -- Seth Arnold | http://www.willamette.edu/~sarnold/ Hate spam? See http://maps.vix.com/rbl/ for help Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Re: Source dependencies: are we ready?
(Sorry, bad manners to followup own email, but more came to me..) On Wed, Oct 27, 1999 at 03:50:06AM -0700, Seth R Arnold wrote: On Wed, Oct 27, 1999 at 03:41:00AM -0700, Joel Klecker wrote: [...] I've eliminated the tetex-bin dependency, BTW. bzip2 hadn't occurred to me as a dependency, but I guess it is. What else? patch? We need to discuss what's build-essential anyway. Here's a start: libc-dev gcc g++ libstdc++-dev patch make dpkg-dev binutils bison autoconf ? bin86 ? ldso ? supporting stuff tar ? cpio ? gzip ? bzip2 ? find ? perl ? .awk ? sed ? less likely, but still possible... curses ? groff/man ? specialized... perl ? wish ? python ? jdk ? (some of the items under 'supporting stuff' I found in the linux kernel Makefile.. :) -- Seth Arnold | http://www.willamette.edu/~sarnold/ Hate spam? See http://maps.vix.com/rbl/ for help Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Re: Source dependencies: are we ready?
Remember the definition of build-essential: + p +It will not be necessary to explicitly specify build-time +relationships on a minimal set of packages that are always +needed to compile, link and put in a Debian package a +standard Hello World! program written in C or C++. The +required packages are called em/build-essential/, and an +informational list will be published separately from this +document. + /p + On Wed, Oct 27, 1999 at 03:50:06AM -0700, Seth R Arnold wrote: [ What's build-essential?] Joel Klecker: libc-dev Yes: gcc Definitely. g++ yes. libstdc++-dev yes. patch Only if something else requires it. (dpkg-source?) make Yes. dpkg-dev Yes. binutils Yes. bison No. autoconf ? No. bin86 ? Do you need this to compile a Hello World? ldso ? Do you need this to compile a Hello World? supporting stuff tar ? Only as a dependency. cpio ? Only as a dependency. gzip ? Only as a dependency. bzip2 ? Only as a dependency. find ? What needs this? perl ? What needs this? less likely, but still possible... curses ? No. groff/man ? No. wish ? No. python ? No. jdk ? No. Remember, this list is supposed to be MINIMAL. BTW, what do you people think of the metapackage idea (see the new Policy draft thread)? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
On Wed, Oct 27, 1999 at 12:16:17PM +0200, Roman Hodek wrote: My personal view of sbuild is that it's a tool for mass builds. If Debian wants to adopt it as replacement for dpkg-buildpackage, please go ahead, I won't mind :-) But it was written with a different intention. How about we just borrow a little code for dpkg-buildpackage from sbuild then? :) I guess for this purpose, dpkg-buildpackage can simply print a big fat warning (by default exiting), with an option to ignore the warnings, and another option to not check the build deps at all. I would like the code that processes the build deps to be consistent for all the programs using it. Since sbuild already has it... :) In this capacity, dpkg-buildpackage will be parsing the unpacked debian/control file, while sbuild will be checking the .dsc, and if apt-get implements it, it will probably parse the Sources.gz and maybe the .dsc for double checking. Ben
Re: Source dependencies: are we ready?
On Wed, Oct 27, 1999 at 03:41:00AM -0700, Joel Klecker wrote: I've eliminated the tetex-bin dependency, BTW. bzip2 hadn't occurred to me as a dependency, but I guess it is. What else? patch? We need to discuss what's build-essential anyway. Here's a start: libc-dev gcc g++ libstdc++-dev patch make dpkg-dev binutils bison According to the proposal, anything that is required for building a simple Hello World .c and .cc is an assumed dependency. Since dpkg-dev is also an assumed dependency, and it deps on make/patch/diff, those are probably assumed too. That just leaves bison as a possible, but I'm not sure. Should dpkg-dev possibly depend on anything we consider to be assumed for build dependencies? Ben
Re: Source dependencies: are we ready?
On Wed, Oct 27, 1999 at 07:22:00AM -0400, Ben Collins wrote: Should dpkg-dev possibly depend on anything we consider to be assumed for build dependencies? I'd create a separate metapackage for that, as I already proposed elsewhere. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
He means have that as an ability, but I don't see that as relevant to what we *need* for source depends to be useful. Yep :-) As an aside, I don't think the present dpkg-buildpackage is a suitable platform for dependency checking, being that it's only a shell script. This was my idea, too. I'm currently at writing a longer mail with some thoughts about this. I've eliminated the tetex-bin dependency, BTW. Ah, no more readlink calls? Fine, deleting it... bzip2 hadn't occurred to me as a dependency, but I guess it is. Yep, it's needed by tar xIf ... you use to unpack the tarballs. What else? patch? Yep, but that's build-essential, as it's already used by dpkg-source. Other dependencies I have registered: gettext and time. gettext is pretty ok, time is a bit unusual but no problem. libc-dev gcc g++ libstdc++-dev patch make dpkg-dev binutils bison Please not bison, it's too specific. My additions (all essential anyway): fileutils shellutils dpkg Roman
Re: Source dependencies: are we ready?
autoconf ? bin86 ? ldso ? All to specific, specially bin86 :-) (it's i386-only...) supporting stuff tar ? cpio ? gzip ? bzip2 ? find ? perl ? tar and gzip are already needed by dpkg and dpkg-source. BTW (contrary to my previous post) I'd say we should omit (binary-)essential packages, they have to be installed anyway on any system. less likely, but still possible... curses ? groff/man ? Never. specialized... perl ? wish ? python ? jdk ? Much too specialized :-) Roman
Re: Source dependencies: are we ready?
BTW, what do you people think of the metapackage idea (see the new Policy draft thread)? Such a metapackage surely will be useful. However, I think the build-essential list still should be written down somewhere :-) Roman
Re: Source dependencies: are we ready?
On Wed, Oct 27, 1999 at 02:46:42PM +0300, Antti-Juhani Kaijanaho wrote: On Wed, Oct 27, 1999 at 07:22:00AM -0400, Ben Collins wrote: Should dpkg-dev possibly depend on anything we consider to be assumed for build dependencies? I'd create a separate metapackage for that, as I already proposed elsewhere. But then dpkg-dev should still depend on that (which would be good and let it get rid of all the other deps it needs/has). Ben
Re: Source dependencies: are we ready?
How about we just borrow a little code for dpkg-buildpackage from sbuild then? :) My idea :-) Please wait for the upcoming post... :-) Roman
Re: Source dependencies: are we ready?
On Wed, Oct 27, 1999 at 08:00:47AM -0400, Ben Collins wrote: I'd create a separate metapackage for that, as I already proposed elsewhere. But then dpkg-dev should still depend on that (which would be good and let it get rid of all the other deps it needs/has). On the contrary: dpkg-dev should depend on what it needs, and the metapackage should depend on dpkg-dev. This way the only thing that needs to be preserved is the name of the metapackage; at some later date dpkg-dev need not be build-essential (think about Klee's dpkg-source, for example). The idea is that you only need to apt-get install the metapackage and whatever the Build-* fields specify to build a package. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
On Wed, Oct 27, 1999 at 01:56:04PM +0200, Roman Hodek wrote: Such a metapackage surely will be useful. However, I think the build-essential list still should be written down somewhere :-) Well, if the metapackage is in the available file, the following shell code will create such written list (untested): grep-available -PX task-build-essential -sDepends -n | tr ',' ' ' build-essential.txt This is trivially automatisable. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
This is trivially automatisable. Ok :-) I simply think it's nicer to have a file under docs/package-developer (besides policy) that clearly says what is build-essential. It doesn't matter if that is built automatically or not. Roman
Re: Source dependencies: are we ready?
On Wed, 27 Oct 1999, Antti-Juhani Kaijanaho wrote: On Wed, Oct 27, 1999 at 03:50:06AM -0700, Seth R Arnold wrote: ldso ? Do you need this to compile a Hello World? I doubt gcc works without ldso ;-) [ Every required-and-essential package should be included in the list, because a broken system is not supposed to be able to compile a Hello World ]. Thanks. -- 379a5162d0e60e56cb1ef0620a8886fe (a truly random sig)
Re: Source dependencies: are we ready?
On Wed, Oct 27, 1999 at 03:35:40PM +0300, Antti-Juhani Kaijanaho wrote: Well, if the metapackage is in the available file, the following shell code will create such written list (untested): ... Last time I checked, apt-get update did not update the available file. -- Raul
Re: Source dependencies: are we ready?
On Wed, Oct 27, 1999 at 09:06:00AM -0400, Raul Miller wrote: Last time I checked, apt-get update did not update the available file. That's true but irrelevant. I was providing an existence proof, not a fully thought-out implementation. I will probably just generate the information at metapackage build time to both the Depends line and the /usr/share/doc file (which can, additionally, be installed in the web pages, if people prefer that). -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
At 13:51 +0200 1999-10-27, Roman Hodek wrote: I've eliminated the tetex-bin dependency, BTW. Ah, no more readlink calls? Fine, deleting it... Actually no, I've simply put readlink.c into debian/scripts and I compile it at build time. Other dependencies I have registered: gettext and time. gettext is pretty ok, time is a bit unusual but no problem. I eliminated time a while back. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Source dependencies: are we ready?
Previously Antti-Juhani Kaijanaho wrote: BTW, what do you people think of the metapackage idea (see the new Policy draft thread)? It's bad and shouldn't be handled by dpkg. There is an excellent strategy for implementing this in frontends, see the Apt UI design for example. In fact libapt already implements most of it iirc and somebody just needs to finish a complete frontend for apt. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgpwHBDD6qCuB.pgp Description: PGP signature
Re: Source dependencies: are we ready?
On Wed, 27 Oct 1999, Raul Miller wrote:
On Wed, Oct 27, 1999 at 03:35:40PM +0300, Antti-Juhani Kaijanaho wrote:
Well, if the metapackage is in the available file, the following
shell code will create such written list (untested):
Last time I checked, apt-get update did not update the available file.
So don't use the available file?
Wakko{jgg}~/work/dsync/buildlib#apt-cache depends apt
apt
Depends: libc6
Depends: libstdc++2.9
Suggests: dpkg-dev
Conflicts: deity
Replaces: deity
Replaces: libapt-pkg-doc
Replaces: libapt-pkg-dev
Pretty easy to automate a list extraction IMHO
Jason
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 12:14:19AM +0100, Julian Gilbey wrote: Just a question which I haven't thoroughly investigated yet: I'm about to add #41232 (source dependencies) to the next policy version. But will this break existing tools? In particular, will the dpkg* tools yet be able to build a package using a Source-Depends: field, or will they die? If the latter, then we need a dpkg NMU (Wichert? Ben?) before this can be placed in policy. Ughh, this is completely different that what I was told. I see no problem with implementing this as written however. Just tell me that it wont change anymore before being implemented? :) As a helpful aside, could you send me a real simple shake down of what the fields are, where they need to go (after dpkg-gencontrol and/or dpkg-source get's done parsing them). Thanks, Ben
Re: Source dependencies: are we ready?
At 00:14 +0100 1999-10-26, Julian Gilbey wrote: Just a question which I haven't thoroughly investigated yet: I'm about to add #41232 (source dependencies) to the next policy version. But will this break existing tools? In particular, will the dpkg* tools yet be able to build a package using a Source-Depends: field, or will they die? If the latter, then we need a dpkg NMU (Wichert? Ben?) before this can be placed in policy. wtf? when did the proposal change to Source-Depends:? there's no evidence of that in the logs. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Source dependencies: are we ready?
At 00:14 +0100 1999-10-26, Julian Gilbey wrote: Just a question which I haven't thoroughly investigated yet: I'm about to add #41232 (source dependencies) to the next policy version. But will this break existing tools? In particular, will the dpkg* tools yet be able to build a package using a Source-Depends: field, or will they die? If the latter, then we need a dpkg NMU (Wichert? Ben?) before this can be placed in policy. wtf? when did the proposal change to Source-Depends:? there's no evidence of that in the logs. Sorry, I was doing things from memory. The proposal says: + p +This is done using the ttBuild-Depends/tt, +ttBuild-Depends-Indep/tt, ttBuild-Conflicts/tt, and +ttBuild-Conflicts-Indep/tt control file fields. + /p and that is, of course, what I was going to use. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 12:15:52AM -0700, Joel Klecker wrote: wtf? when did the proposal change to Source-Depends:? there's no evidence of that in the logs. *My* proposal has never changed that way (#41232). The fields are: Build-Depends: Build-Depends-Indep: Build-Conflicts: Build-Conflicts-Indep: -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 09:52:09AM +0100, Julian Gilbey wrote: At 00:14 +0100 1999-10-26, Julian Gilbey wrote: Just a question which I haven't thoroughly investigated yet: I'm about to add #41232 (source dependencies) to the next policy version. But will this break existing tools? In particular, will the dpkg* tools yet be able to build a package using a Source-Depends: field, or will they die? If the latter, then we need a dpkg NMU (Wichert? Ben?) before this can be placed in policy. wtf? when did the proposal change to Source-Depends:? there's no evidence of that in the logs. Sorry, I was doing things from memory. The proposal says: + p +This is done using the ttBuild-Depends/tt, +ttBuild-Depends-Indep/tt, ttBuild-Conflicts/tt, and +ttBuild-Conflicts-Indep/tt control file fields. + /p Ok, this is what I have as recognized fields in the current dpkg CVS. The wording in that new proposal for bug #41232 through me for a loop. Anyway, all that is left to be done for dpkg is have dpkg-buildpackage (and possibly dpkg-source?) do something when the build depends aren't satisfied. Just so I don't have to go looking all over creation, what was the general consensus on how dpkg-* scripts should handle and react to these fields? Ben
Re: Source dependencies: are we ready?
At 00:14 +0100 1999-10-26, Julian Gilbey wrote:
Just a question which I haven't thoroughly investigated yet:
I'm about to add #41232 (source dependencies) to the next policy
version. But will this break existing tools? In particular, will the
dpkg* tools yet be able to build a package using a Source-Depends:
field, or will they die? If the latter, then we need a dpkg NMU
(Wichert? Ben?) before this can be placed in policy.
The tools ignore fields that they don't understand. However, dpkg-dev
does need to be modified to know the fields specifically or it will
not pass them through from the control file (which is done in dpkg
CVS).
I do have a problem with the text for policy; it does not explain the
difference between Build-Indep-{Depends,Conflicts} and
Build-{Depends,Conflicts}.
I don't have a clear idea of the difference, and I participated in
the discussion of the proposal.
Someone who simply reads the new policy will have no clue (besides
perhaps guessing that the -Indep form has some relation to
binary-indep) what exactly the difference is and in what situations
each is used.
--
Joel Klecker (aka Espy)Debian GNU/Linux Developer
URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED]
URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Source dependencies: are we ready?
At 06:31 -0400 1999-10-26, Ben Collins wrote: On Tue, Oct 26, 1999 at 09:52:09AM +0100, Julian Gilbey wrote: Sorry, I was doing things from memory. The proposal says: + p +This is done using the ttBuild-Depends/tt, +ttBuild-Depends-Indep/tt, ttBuild-Conflicts/tt, and +ttBuild-Conflicts-Indep/tt control file fields. + /p Ok, this is what I have as recognized fields in the current dpkg CVS. The wording in that new proposal for bug #41232 through me for a loop. Anyway, all that is left to be done for dpkg is have dpkg-buildpackage (and possibly dpkg-source?) do something when the build depends aren't satisfied. There's also the extended syntax for the fields, it is possible to specify architecture. e.g. for glibc: Build-Depends: kernel-headers-2.2.12 [!hurd-i386 !m68k], kernel-headers-2.2.10 [m68k], hurd-dev [hurd-i386], gnumach-dev [hurd-i386], mig [hurd-i386] It'd be cool to have dpkg proper support this syntax too. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Source dependencies: are we ready?
Previously Julian Gilbey wrote: I'm about to add #41232 (source dependencies) to the next policy version. But will this break existing tools? Yes. And I won't think I want to change dpkg and friends to accept the fields until someone comes up with a complete implementation. I'm annoyed though, that everyone is completely ignoring a *working* implementation of source-dependencies simply because nobody is willing to clean it up a little and package it. How can that happen??? Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgpdRsd1kcaf6.pgp Description: PGP signature
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 01:54:58PM +0200, Wichert Akkerman wrote: Yes. And I won't think I want to change dpkg and friends to accept the fields until someone comes up with a complete implementation. How do you define complete implementation? The build daemon folks have had a working implementation for ages, all that needs to be done is to get that system to parse these fields. I'm annoyed though, that everyone is completely ignoring a *working* implementation of source-dependencies simply because nobody is willing to clean it up a little and package it. How can that happen??? What are you talking about? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 04:30:50AM -0700, Joel Klecker wrote:
I do have a problem with the text for policy; it does not explain the
difference between Build-Indep-{Depends,Conflicts} and
Build-{Depends,Conflicts}.
The difference is clearly defined by the amendment. The
Build-{Depends,Conflicts}-Indep fields will be consulted only when the
architecture-independent packages are being built. In other words, they
will *not* be consulted when doing a architecture-dependent packages only
build (for example, like the build daemons do).
Someone who simply reads the new policy will have no clue (besides
perhaps guessing that the -Indep form has some relation to
binary-indep) what exactly the difference is and in what situations
each is used.
Here's a rule of thumb: if your source package builds only
architecture-dependent packages, use only Build-{Depends,Conflicts}.
If it builds only architecture-independent packages, you get too choose.
If it builds both, use Build-{Depends,Conflicts} to specify build-time
dependencies needed to build the architecture-dependent packages and
put in Build-{Depends-Conflicts}-Indep whatever additional packages are
needed to build the architecture-independent packages.
I really wish you had spoken up back then when we could have made the
wording more clear on this.
--
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
(John Cage)
Re: Source dependencies: are we ready?
I'm annoyed though, that everyone is completely ignoring a *working* implementation of source-dependencies simply because nobody is willing to clean it up a little and package it. How can that happen??? Aehm, what do you mean? For just getting src-deps working, it's only necessary that the appropriate fields are passed through (better without warnings :-) Ok, we wish that src-deps are also checked, but this isn't too hard (and IMHO it belongs into dpkg-source -x). sbuild (used by the build daemons) already understands src-deps in the control file. Do you consider this a working implementation? However, it's not packaged yet :-), but more because the whole buildd setup stuff is rather complicated. I've made some progress here lately, but it isn't finished yet. Roman
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 04:18:55AM -0700, Joel Klecker wrote: At 06:31 -0400 1999-10-26, Ben Collins wrote: Ok, this is what I have as recognized fields in the current dpkg CVS. The wording in that new proposal for bug #41232 through me for a loop. Anyway, all that is left to be done for dpkg is have dpkg-buildpackage (and possibly dpkg-source?) do something when the build depends aren't satisfied. There's also the extended syntax for the fields, it is possible to specify architecture. e.g. for glibc: Build-Depends: kernel-headers-2.2.12 [!hurd-i386 !m68k], kernel-headers-2.2.10 [m68k], hurd-dev [hurd-i386], gnumach-dev [hurd-i386], mig [hurd-i386] It'd be cool to have dpkg proper support this syntax too. You don't ask much do you? :) I haven't tested it, but I think dpkg will simply apply the contents of the field verbatim. As for actually doing something with the info, that is going to take extra work. Has anyone else started on getting dpkg-buildpackage to make use of this info? I know that sbuild currently uses them (to what extent, I'm not sure). Ben
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 04:30:50AM -0700, Joel Klecker wrote:
I do have a problem with the text for policy; it does not explain the
difference between Build-Indep-{Depends,Conflicts} and
Build-{Depends,Conflicts}.
I think you mean the packaging manual, and the diff says quite
clearly (or at least it would be if it weren't in SGML ;)
taglist
tagttBuild-Depends/tt, ttBuild-Conflicts/tt/tag
item
p
The ttBuild-Depends/tt and ttBuild-Conflicts/tt fields apply
to the targets
ttbuild/tt, ttbinary/tt, ttbinary-arch/tt
and ttbinary-indep/tt.
/p
/item
tagttBuild-Depends-Indep/tt, ttBuild-Conflicts-Indep/tt/tag
item
p
The ttBuild-Depends-Indep/tt and
ttBuild-Conflicts-Indep/tt fields apply to the
targets ttbinary/tt and ttbinary-indep/tt.
/p
/item
/taglist
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 04:51:23PM +0200, Wichert Akkerman wrote:
Previously Antti-Juhani Kaijanaho wrote:
How do you define complete implementation?
A dpkg-source that:
a) supports build-dependencies
b) supports multiple patches
c) can setup a buildroot and start building everything that is needed to
build a package
Personally I don't think dpkg-source can enforce this. At the point of
unpacking, we don't even know what targets we are going to build (arch,
indep, both?). Dpkg-buildpackage would be a better place to say you don't
have all the needed deps, also I don't think that dpkg-source should in
anyway attempt to setup a buildroot.
Right now sbuild is about the best thing we have for all of this, I would
personally love to have it directly in dpkg-dev since it's pretty self
standing and would satisfy all of these issues. Anyway, most of the
majority of people that will be using Build-* deps, will be using sbuild
anyway (no matter what you put into dpkg-{source,buildpackage}, and yes,
I'm refering to the autobuilders). So why not give everyone else the same
tools that are used by the folks that brought on this added feature in the
first place, that way we also avoid duplication of effort.
Ben
Re: Source dependencies: are we ready?
Previously sparc porters wrote: Personally I don't think dpkg-source can enforce this. The name dpkg-source here is a bit if a misnomer; it is in fact the name of a package that includes new versions of dpkg-source, dpkg-buildpackage, dpkg-genchangers, etc. I have the tarball available for anyone who wants to play with it. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgprqeZ4gbx75.pgp Description: PGP signature
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 07:13:27PM +0200, Wichert Akkerman wrote: Previously sparc porters wrote: Personally I don't think dpkg-source can enforce this. The name dpkg-source here is a bit if a misnomer; it is in fact the name of a package that includes new versions of dpkg-source, dpkg-buildpackage, dpkg-genchangers, etc. I have the tarball available for anyone who wants to play with it. I still think sbuild is the way to go. Since it already handles local overrides, downloading/installing/removing packages needed to do the building as well as removing/installing packages that were shifted from the Build-* deps once the build is complete. On top of that, it can download the sources by specific version and distribution and it's already well tested and proven. Ben
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 07:13:27PM +0200, Wichert Akkerman wrote: The name dpkg-source here is a bit if a misnomer; it is in fact the name of a package that includes new versions of dpkg-source, dpkg-buildpackage, dpkg-genchangers, etc. I have the tarball available for anyone who wants to play with it. I would be interested in taking a look at it. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 09:02:59PM +0200, Wichert Akkerman wrote: Previously sparc porters wrote: I still think sbuild is the way to go. I still think sbuild is not the way to go and would rather see sbuild modified to handle the new source format. Oh, in case someone hasn't noticed: this is the rumoured new source format from Klee Dienes. If you want to test it grab klee.tar.gz from ~wakkerma on master. You will need to have python installed btw. Sbuild calls dpkg-source to unpack, what does it have to do with the source format?! All it has to do is call whatever executable is needed for the unpacking. It _already_ handles _everything_ else, _and_ the Build Dependencies. My suggestion is to keep the enforcement of build deps out of raw tools like dpkg-source and dpkg-buildpackage and in specialized tools like sbuild (which already has it) and apt (which already builds and downloads packages, so it can handle checking build deps with modifications). Ben
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 03:46:23PM -0400, Ben Collins wrote: Sbuild calls dpkg-source to unpack, what does it have to do with the source format?! All it has to do is call whatever executable is needed for the unpacking. It _already_ handles _everything_ else, _and_ the Build Dependencies. My suggestion is to keep the enforcement of build deps out of raw tools like dpkg-source and dpkg-buildpackage and in specialized tools like sbuild (which already has it) and apt (which already builds and downloads packages, so it can handle checking build deps with modifications). I agree with Ben that dpkg-source should not care about build dependencies (hey, it only unpacks the source, I only need ar and tar and gzip for this!) dpkg-buildpackage should optionally verify the build dependencies only. apt should have an option to fulfill source depends for a set of packages. sbuild is overkill for most people. Also, it is tightly related to the wanna build autobuilder. It is pretty much hackish, and I would rather see something replacing sbuild than vice versa. All IMNSHO. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
