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
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
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
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
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
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
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
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
:-)
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,
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++
(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,
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
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
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++
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] %
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,
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
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
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
How about we just borrow a little code for dpkg-buildpackage from
sbuild then? :)
My idea :-) Please wait for the upcoming post... :-)
Roman
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
+
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
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
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
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
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
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
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
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
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,
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
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:
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
48 matches
Mail list logo
