> it means that very rarely can Build-Depends-Indep used, and also
> that build daemons building only architecture-dependent parts of the
> package need often install also everything needed to build the
> architecture-independent parts. This is not good.
Right.
> However, to make use of the prop
> *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 overco
> 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
> 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
> 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 che
> 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 dependenc
> What about packages using debstd, or dpkg-gencontrol? I presume dpkg
> will be patched such that such packages will still build?
Hae? debstd can call dpkg-shlibdeps in the by Wichert says; no change
in the package itself. dpkg-gencontrol is totally independent. Any why
patch dpkg???
Roman
> 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 t
> 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
> 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
> 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
> e
> 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,
> *Parts*, fine, I have no problem with parts. I was just a little
> croggled by the example of trying to autogenerate *all* source
> dependencies for the debian-policy package.
The automatically generated parts will be only -dev packages for
shared libs.
> I think it may turn out to be more hai
> 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 i
> 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 re
> > - dpkg-source extracts the Build-* fields from the .dsc and writes
> >them to debian/build-depends.
>
> Sounds a bit too much like magic for me. It should not be necessary to make
> such wiggles to build a package succesfully. By all means make this
> optional. Working from the dsc is fi
> I wonder though, if we are going to do this if it might not make
> sense to rethink the whold sourcepackage-format we have now anyway.
I think both things are independent. If we go for what I proposed, you
still can exchange dpkg-source (the script) to do something more
elaborted than now.
> I
> 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
> OK, I've just tried to calculate the build-time dependencies for
> debian-policy, and here are some thoughts.
>
> It's not easy. In fact it's *really* not easy.
If you really want to (more or less) automate it, it's really not
easy... But for most packages, src-deps are rather clear. It seems
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,
> 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
> How about we just borrow a little code for dpkg-buildpackage from
> sbuild then? :)
My idea :-) Please wait for the upcoming post... :-)
Roman
> 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
> 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-)essen
> 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,
> > 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
:-) w
> 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 glib
> 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 th
> 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
> deb
> 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
> 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
> 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 packa
> Umm, since the intent is not to make the old way of doing things
> incorrect, we can do one of two things. Here are psuedo patches that
> detail the approaches. (I personally prefer the second approach).
The second one looks fine (except some typos).
Roman
> I was thinking more along the lines of "you should use -g in the
> default build, unless you provide a build that honors
> BUILD_DEBUG=y".
>
> This keeps us from forcing current packages to move to this, in the
> even that it may be downright insane to modify the build in this
> way.
Hmm... I
> 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 th
> I think I like this. One can then set the variable, and do
> dpkg-buildpackage, or even use a build daemon to build a whole set
> of debuggable packages, should the need arise.
Yep.
> One can still suggest that a two line addition
> build-debug: BUILD_DEBUG=y
> build-debug: bui
> 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
>
> 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 packa
> 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
> 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 s
> 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
> 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 o
> 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
> 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
tro
> 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 th
> 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
> 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
> 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 pa
> 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-*' t
> 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
> - The fields change as follows:
>Depends -> Build-Depends
>Arch-Depends(removed as suggested by Roman Hodek)
>Indep-Depends -> Build-Indep-Depends
>Conflicts -> Build-Conflicts
>
> 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 s
> I realize that these would be in the first stanza of the control
> file, and therefore don't technically conflict with the binary
> Depends/Conflicts fields, but I think it's going to lead to a lot of
> confusion, particularly for new maintainers. Why not name them
> Src-Depends, Src-Indep-Depen
> IMHO, we will have to name specific packages. However, unlike Roman,
> I hesitate to provide a huge default set. "make" of course sounds
> reasonable, "dpkg-dev" anyway, but "texinfo" not. texinfo *was* in
> the tetex packages, and I had some trouble to compile some packages
> on the Hurd before
> 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
> > 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
> The build bot people have a partial solution of their own. Yet, we
> still don't have a general way of specifying these dependencies in
> our packages.
Yep, and I agree that we should have such a thing. The "partial
solution" you mention is a (complete) central database of source
dependencies,
> > 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
> 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
> 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
> 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
> o
> 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 th
> Hmm, I usually keep my current version of the sources of my package
> locally. It's a small effort to implement any diffs submitted to the
> BTS to my development version in any case. So, I don't think that "a
> sourceful NMU takes away the sources under his feet" is applicable.
But many people
> 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
> 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 misund
> 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
> > 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,
> 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
> obso
> 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 th
> 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 sho
> 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
(on
> 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,
> 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 usu
> Except dpkg is written in C, only dselect uses C++.
I was thinking about the package dpkg, not the binary of the same
name... But I hope my intentions with the example were clear :-)
Roman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAI
> 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,
depe
> Such automation (silly as it is) would be absolutely trivial to
> implement,
Not even that... you also need some kind of source dependencies,
except you want to install the whole of Debian on the build machine,
plus a bit more (e.g. Tcl/Tk sources etc.)
I'm currently trying to set up a semi-au
> 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 d
> 4. Noone but the maintainer of a package (or someone acting on their
> request) should close its bug reports.
Why not the submitter himself?
Roman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
79 matches
Mail list logo
