Then explain to my why it worked perfectly for me even if I did not
list all those libraries in the link command? Seems like the linker
is smart enough..
Yes, it is. (But only for shared libs, of course, static libs have no
NEEDED entries.)
Roman
*static* libraries are conisiderably different and in that case you
do need to mention all of the libraries that all of the sub
libraries touch. However, I thought gnome used libtool which takes
care of that through its .la files, making this whole point moot.
Yep, libtool tries to overcome
In woody dpkg will use a different method to determine on which
libraries a package should depend. Until now dpkg-shlibdeps has used
the output of ldd to determine which libraries are needed. This will
be changed to using objdump.
[...]
And now for the connection to package management: a
1) It allows for cross compilation (without the dpkg-shlibdeps
replacement in dpkg-cross)
What Wichert wants is basically the objdump-based variant in
dpkg-cross. It does nothing else than he plans to do.
Aehm, wait, one change is needed: dpkg-cross' shlibdeps current
expects all libraries to
How do we ensure that someone upgrading a package from potato to woody
pulls in all of the required libraries? As a concrete example,
/usr/bin/foo in the foo package depends upon libbar directly and
libbar depends upon libbaz indirectly. In potato, libbar does not
declare a dependency upon
Right, and I'm willing to bet that happens. Not everyone uses
debhelper..
Sure, not everyone, but many. And not to forget, (AFAIK) debstd does
the same. Indeed, I always thought that shlib packages should depend
on the libs they need already... :-)
I guess it could be done as a lintian check
So imlib-config shouldn't list any of those libraries since libImlib
is already linked to them.
I guess imlib-config lists those libraries for the case of static
libs. Then you don't have automatic link-in of secondary libs...
Roman
And creates a symlink.
..but not for man pages in /usr/share/man.
a) this seems a pretty minor problem, given people will be able to
read /usr/man/foo and /usr/doc/foo
The man in slink doesn't look at /usr/share/man !
b) Adding two lines of code to debian/rules is so mind-blowingly
easy
The fact that most maintainers don't need to perform builds on the
non-x86 architectures could use some clarification.
The programmer's reference by Adam contains a fine section about
portability etc.
Roman
debhelper only affects the .deb file, and it should produce correct
.debs regardless of version. mybe some compilers etc. seems like
FUD to me.
Wrong. Take as example that the potato debhelper installs docs into
/usr/share/doc, and the stable one to /usr/doc. Same for man pages...
OK, so
Also, this would rely on debian/rules clean completely reversing
the effect of a build, and I can tell you right now, this was not
true of *any* package I have adopted
It's required to do so :-) And if you (like me) build sources during
each round of the development cycle, you actually rely
No, the problem is where to find the information after the source is
unpacked. And you gave the answer: In the dsc file. It should be
copied to the target directory (the parent directory of the package
tree) by dpkg-source -x just as the orig.tar.gz file is.
[...]
I think my idea above is
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
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
:-)
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
How about we just borrow a little code for dpkg-buildpackage from
sbuild then? :)
My idea :-) Please wait for the upcoming post... :-)
Roman
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
Here are some thoughts how source dependencies can be reasonbly
implemented for now, and kind of a vision for the future:
- dpkg-source extracts the Build-* fields from the .dsc and writes
them to debian/build-depends.
This is necessary, as the actual checking is done before building,
I like this, makes it easily parsible by other programs.
That was the intention :-)
I heard other arguments for and against this. Sometimes I like to
have my build lay around so that I have _exact_ copies of what I
just built, and can go in and see if anything went wrong (make sure
all 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
Let's assume that you care to keep executables with debugging
symbols around. In that case, the old recommendation would
have you build the package once. The new recommendation
would have you compile twice. Time saved?
Let's assume that you don't care to keep executables with
debugging
Should these packages built with BUILD_DEBUG turned on have a
different name (i.e. libgtk1.2-dbg) than the standard packages? Is
there an easy way to do this other than replicating control file
entries?
Hmm... I'd say they shouldn't. They have the same functionality as the
non-debug
This is the final form (or, at least, I am done with this). I am
forwarding this to bugs.debian.org
My ok again for the second variant.
Roman
It worries me that we're going to become *very* dependent on a
specific version of make all of a sudden.
Why? Where? The only thing that's GNU make specific is the variable
defintion as a dependency, i.e. the suggested implementation of the
build-debug target. But that's only a recommendation,
However, have you looked at the cost of this proposal? This entails
that one massage upstream Makefiles (or several Makefiles) to take
not of an environment variable to add debugging flags. That is more
difficult than a static, one time edit of the Makefiles involved to
add the -g and the
The package can by default build without -g if it also provides a mechanism
to easily be rebuilt with debugging information. This can be done by providing
a build-debug make target, or allowing the user to specify BUILD_DEBUG=yes
in the environment while compiling that package.
build-debug: BUILD_DEBUG=y
Is that a GNU make feature that you can set vars at the place where a
dependency is expected?
Roman
No. The dpkg-architecture terminology may confuse you. Here's from
Packaging Manual 3.0.1.0 section 3.2.1 (debian/rules - the main
building script): ... BUILD for specification of the build machine
or HOST for specification of the machine we build for.
Hmm... it guess I was confused by the
This deadline is almost at hand. I've produced a final draft of the
amendment for your review.
I agree with this version.
If it is necessary, a separate amendment can establish a way to
conditionalise based on build architecture.
You mean the target architecture?
The set definition
Does it run with lprng but only build with the real lpr? If so, its
a bug, that it doesn't compile and should be fixed. If it doesn't
run or compile with lprng, it should depend on the real lpr.
I don't know if it runs with lprng But in any way, it can't depend
only on the real lpr, as
I´d prefer a syntax in the style of /etc/exports, e.g.
Build-Depends: package1, package2(CPU1), package3(!CPU1),
package4(SYSTEM2-CPU2, SYSTEM3-*), package5 | package6(CPU1),
package7(CPU1, = 2.0), package7(!CPU1, = 2.1)
It looks a bit easier to read (and create) to me than the prefix
Are the -Conflicts headers really necessary? So far I have not been
able to think of a use for them, and they complicate the task of the
build daemons (install everything needed to build this package)
unnecessarily.
That's not really true. The parsing is nearly the same, and it's no
trouble
Can we use a format that is more inline with the rest of the depends
stuff? Perhaps:
pkg (= 2.1 i386)
With the 'i386' being whatever specification you want to dream up.
(optional of course)
At least better to parse than package7(CPU1, = 2.0), as the version
can't contain
What if you can only uninstall the package by deconfiguring another one
that you need? Take this situation:
foo-source has
Build-Depends: gnu1 | gnu2
Build-Conflicts: bar
gnu1 has
Depends: bar
Currently bar and gnu1 are installed. Will your five lines of code be
This shouldn't be too hard. You only need a syntax for it. There are several
possibilities:
Build-Depends: hurd-all:gnumach-dev, hurd-all:hurd-dev,
linux-all:kernel-headers-2.0.36
The prefix idea is good, here a suggestion for concrete syntax:
ARCH:packagerestricted to ARCH
Your naming is weird ;) s/ARCH/CPU/, s/OS/SYSTEM/ and I'm your
friend.
If it makes you lucky, think the vars re-named :-) But it really makes
no difference, I meant exactly the same as you, i.e. ARCH == cpu.
Looks good to me. I don't know how many logical operators we should
support, but it
I strongly agree with the proposal.
Nice to have you on the boat, too :-)
I disagree with Roman's suggestion that we should remove the Arch-
versions because they'd not be used often. I think it important that
the resulting scheme be orthogonal. It should also parallel the
`binary-*'
I would like to use this suggestion. Comments?
See my previous mail: I'd say the -Arch variants are unnecessary, but
if everybody wants them for clearness of design, I won't oppose.
Sounds good. Actually, that was what I had originally in mind. If
there are no objections, I'll make this part
- The fields change as follows:
Depends - Build-Depends
Arch-Depends(removed as suggested by Roman Hodek)
Indep-Depends - Build-Indep-Depends
Conflicts - Build-Conflicts
Arch-Conflicts (removed
Yes, consider that a typo. I will not submit another patch as the
fix is obvious.
Yep, that's what I thought as I seconded the proposal :-)
Roman
First of all, I should make it clear that in practice, this is
probably even *less* important than the previous technical objection.
But it is, still, a *technical* problem, however minor.
Well, if the first stanza is global, how about being able to put the
fields in the other stanzas too, to control dependancies on a
per-binary-package basis? You would need to name them prefix,
though.
This seems possible, but I can't see the real advantage of it. You
really seldom build
For my current system I have defined the following packages as
build-essential:
I wanted to avoid naming specific packages in Policy (I only named two in
the proposal, make and dpkg-dev), since packages change and it would be a
pain in the rear to change policy every time GNU Libc
Small comment: I like the informal way the build-essential
packages are described. However, for practical reasons, it would
help to specify also which ones they are at a given time. For
example:
[...] and packages which are required for compiling and linking a
minimal Hello World program
What's then the difference in semantics of Maintainer: and Uploader:
in the .changes? Maintainer: always the source maintainer, and
Uploader: is different only for NMUs?
NMU's and recompiles for other architectures.
Ok...
Roman
Eeks, no! I don't want the Maintainer: field to change on every NMU
-- that would be ghastly, especially if people think to use dpkg -s
to get in contact with the maintainer.
I was talking about Maintainer: in the .changes, not in the package
itself.
Roman
1) add a Compiled-By field to the control-file
Aehm, to debian/control?? That doesn't make sense. debian/control
contains static infos, whereas who compiled a pkg is dynamic.
Oh, I see, you probably mean the control file of packages. Then we
have the following problem: The name of the builder
A Compiled-by: field would be useful.
Yes (no matter what the exact name is...)
I also still think the Maintainer: entry in a .changes file should
be renamed..
If we have a Compiled-By: field, then Maintainer: can change its
semantics so that it needs no renaming anymore...
What about
Is there a mistake in the Debian Developer's Reference I must
admit, I find it surprising, a new field would be better. Here is an
extract:
[...]
I haven't tested it, but I presume that the -m option overrides
the value for Maintainer, but the documentation is a bit unclear
on this.
Finally, I'd like to hear for any listening porters (Roman?) about
why binary-only NMUs are a necessary part of their porting workflow.
I understand they are simply a lot faster to produce in cases where
minor, interactive style hacking is required on a package.
First to clear up a
If policy is changed that for portability issues immediate normal
NMUs are permitted, then I'd have no problem in doing this. The
point is that currently it is _not_ policy, and I'd invoke the wrath
of those developers who don't immediately understand the problem,
and who subsequently feel
Since we cannot rebuild for all architectures simultaneously and do
not want to withdraw binaries or wait with porting,
*we MUST be able to have more than one source version in our archive*.
[...]
i. Simply have them side by side, with some kind of way of making
obsolete
Perhaps we should relax this policy, then.
I tend to agree. The wait seems to be the crux of the problem. Perhaps we
could let porters make NMU's with no wait at all?
This would be helpful in some cases, but doesn't solve the problem
that other archs have to recompile that NMU version,
That's right. This could be done occasionally out of cron, though.
There's no harm in extra old source packages hanging around for a
bit.
Ok.
No, I don't think so. The FTP site and the BTS are definitely not
the `same place' according to the GPL. For this to be true we'd have
to make sure
This is an interesting idea, which could be investigated further.
Ok, then we could elaborate that idea...
This probably ought to apply to _any_ NMU, not just an arch-specific
one.
Yes, that was my intention (if I understand you right). If an NMU
doesn't upload the complete source, it
This needs to be fixed, then. Unless we can guarantee that the same
version of the same package will always work on all architectures,
we need to be able to have differing source versions simultaneously
while portability issues are sorted out.
I think Paul meant something different: If the
I almost hate to suggest this, as it has the potential for much
evilness, but would it be possible to somehow mark diffs as specific
to some arch only?
[...]
Having slept a night over the issue :-), I had a similar idea.
If Ian says the patch must be available also on the FTP site, not
This is NOT ON, and is NOT ALLOWED according to the GPL, and ought
to be prohibited by our policy.
It's the consent of many porters (including James Troup, ..., me, ...)
that we don't break the GPL by bin-only NMUs, as the complete source
is still available in an official way: first the usual
GPL v2, s3, last para, emph mine:
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code _from the same place_ counts as
distribution of the source code, even
I was assuming all of the Debian dev packages would be installed on
these build hosts.
These are myriads, too :-), and the source dependencies of package
aren't so uniform... For example, some packages need specific versions
(happened with gimp/lingtk-dev), depend on emacs being present,
When a database package is purged, the implication is that the data
stored in the database should also be deleted. Therefore I have
added the instructions to delete the data to postgresql's postrm.
However, since it is possible to flag whole groups of packages for
purging when using
63 matches
Mail list logo
