Re: Should -dev packages providing .pc files depend on pkg-config?
On Mon, 2008-04-07 at 22:12 -0700, Steve Langasek wrote: > Any package that wants to use .pc files during its build is going to invoke > pkg-config directly, and changing your -dev package to recommend a different > means of linking to the library won't cause this reference to disappear. > That's a build-dependency. It's also a lot of packages - does such a dependency ever become inferred by other packages? It probably shouldn't, for your reasons above, so this would appear to be a case for a lintian check. If ./configure exists and calls pkg-config or configure.in|ac calls pkg-config or uses an m4 macro that calls pkg-config, the package should build-depend on pkg-config ? (We don't seem to have many lintian checks on Build-Depends.) I think the -dev package should not depend on pkg-config - whichever packages choose to use pkg-config to retrieve the data in the .pc file needs to depend on pkg-config. The -dev package doesn't call pkg-config. IMHO, the package providing the .pc file has no need to force any dependency on packages using the -dev. It is perfectly possible to avoid pkg-config but if you are linking against several -dev packages which all provide .pc files, it is inevitable that the package will be better off with pkg-config. This, in many ways, is no different to a build-depends on debhelper or dpatch. The package is using an existing tool as a direct component of the build in situations where another method might be possible (hardcoding the --libs and --cflags output) but not usually desirable. Yes, packages do build without debhelper but it is certainly easier (and desirable for most packages to avoid repeating the same bugs) to use debhelper. Similarly with pkg-config - you can build packages without it but it does make life easier and it does solve some problems inherent in other methods. (It brings in one or two problems of its own too.) (In terms of cross-building / debian-xcontrol, Simon, it's a Build-Depends-Tool.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?
Hi, On Monday 07 April 2008 19:57, Peter Jordan wrote: > why are the keyrings of debian-multimedia.org and debian backports not > in the official repository of debian? I guess this was answered already in this thread :-) > At the moment you have to install untrusted keyrings before you can use > these repositories. No need to do this without a trust path at all, it just needs five easy and documented steps to add those keys with a trust path, for the backports archive see: http://wiki.debian.org/DebianEdu/Documentation/Etch/HowTo/Administration#head-136bb7e75e07e8b6463e6b30761ac51776c5c27d That said, I would appreciate debian-backports-archive-keyring package in Debian main, just like there is a debian-edu-archive-keyring. I wouldn't want a debian-multimedia-archive-keyring package in Debian (main), as this archive doesnt promise to comply to the DFSG as the other three archives do. Contrib would probably fine. ITPs anyone? regards, Holger pgpLE4hCmF2dl.pgp Description: PGP signature
Bug#474965: ITP: libxml-feedpp-perl -- Parse/write/merge/edit RSS/RDF/Atom syndication feeds
Package: wnpp Severity: wishlist Owner: "Adrian 'Dagurashibanipal' von Bidder" <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm currently investigating this perl module; I'll package it or close or rename to RFP depending on how complex this stuff is. * Package name: libxml-feedpp-perl Version : 0.34 Upstream Author : Yusuke Kawasaki, http://www.kawa.net/ * URL : http://search.cpan.org/dist/XML-FeedPP/ * License : Perl Programming Lang: Perl Description : Parse/write/merge/edit RSS/RDF/Atom syndication feeds "XML::FeedPP" is an all-purpose syndication utility that parses and publishes RSS 2.0, RSS 1.0 (RDF), Atom 0.3 and 1.0 feeds. It allows you to add new content, merge feeds, and convert among these various formats. It is a pure Perl implementation and does not require any other module except for XML::TreePP. - -- System Information: Debian Release: lenny/sid APT prefers stable APT policy: (700, 'stable'), (600, 'testing'), (86, 'unstable'), (60, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23-1-686 Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: get my key from http://fortytwo.ch/gpg/92082481 iKcEARECAGcFAkf7JrlgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l65OQAnRQekt3JvOgxwnIez796Ovuf iw+3AKCHT7EqW4FVJ4dJrIa5lqBtu3frQg== =AXBv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: too many conflicts/replaces
Nikita V. Youshchenko debian.org> writes: > > > 2008/4/4, Nikita V. Youshchenko debian.org>: > > > Martin Schr?der wrote: > > > > I'm trying to create a package that will when installed > > > > automatically replace all TeX packages on the system with our > > > > version of TeX. > > > > > > Don't all debian tex packages depend, directly or indirectly, on > > > tetex-base or texlive-base? You probably could create your own -base > > > package that conflicts with those, and then pre-depend on it? (Just kind-of-back from vacation, and I don't know whether this has been discussed on debian-texmaint) No, tetex-base is an empty package which hopefully can be removed before lenny is released, and texlive packages depend on texlive-base-bin which also provides the tex and pdftex binaries. > > And then I'd get a conflict when installing that package. > > Why? > > Won't apt-get/aptitude handle proper removal/installation actions for you? I think it would. Unless Martin actually wants a parallel installation? Maybe dpkg's diversions would help here? Martin, which files do you need to replace except the binary and pool files? Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Should -dev packages providing .pc files depend on pkg-config?
* Manoj Srivastava <[EMAIL PROTECTED]> [080407 20:19]: > > Here I have to contradict. No -dev package should ever depend on a > > compiler or linker, even if that tool was not already in > > build-essentials. > > Can you provide some rationale for this assertion? I can see why > one might not tie the development tool very strongly with a particular > compiler or compiler version, to allow a developer to use it with an > alternative development tool, but I can see why one may want to depend > on a generic foo-lang-compiler-or-interpreter virtual package. > > There is obviously a trade off here -- the need to the > development package to be useful on installation, by ensuring that the > tools required to use the package are also installed, versus the need > to allow people to use the package with alternate developer tools. Ar > there other considerations and use cases you have in mind? - There are multiple compilers. Even within gcc there are multiple versions which look as different compilers from a package standpoint. No alternative list in a dependency can ever be complete. Every new compiler may work for some -devs and for some not, so even virtual packages will often tend to pull the wrong thing in. - No compiler is an essential package[5]. So forcing people to install them or equivs generated pseudo packages just to use their self- compiled unpackages compiler would show there is something very wrong. (Building your own compilers may not be a general use case. But when a -dev package has so special needs that the point before this does not sounds confincing, I'd assume it has so special compiler requirements that people building unpackaged versions would actually be quite common). - Classic asymmetry of dependencies. When you look at dependencies as "foo is only useful with bar", we are currently missing many dependencies and would have to add so many that we hardly get a useful system. Having a compiler is not enough for a -dev package to be useful. You also need a source to compile. (which cannot be even expressed as dependency). And a library itself is totally useless without any binary linking against it[1]. But no library depends on some virtual user-of-lib package, though it would make deinstalling no longer used packages so much easier. . Additionally to many unexpressable things, this would create a large amount of cyclic dependencies, which our tools cannot properly handle[2]. So the point of an dependency is "foo only works with bar installed" (or the functionality definition from policy): A library works (as library) when things can link against it, i.e. when all it NEEDED sections are fullfilled. An application works (as application) when it can be run according to it's supposed purpose (i.e. only missing input data that is supposed to be written to use it). An -data package works when all the data in it is useable (i.e. does not include or reference[3] other data not in the package itself and not in a package it depends), but does not depend on a package doing anything with this data. And a -dev package in my eyes works when a preprocessor can include the header files (i.e. #included header files are there for a significant amount of functionality) and/or a suitable linker can create executables from it (i.e. there are .so or .a files working in enough cases to be significant). The compiler and linker are here things that use it the content of the package. As are a program using the library users of a library and not a dependency. (or as a shell is a user of an application and not the dependeny of a program[4]) > I see recommends as a middle ground between a depends and a > suggestions; can you articulate why this middle ground is unaceptable, > as you assert above? My point is that a recommends is no middle ground. A recommends is just a dependency that is not absolute. Thus limiting the negative effects from extremly annoying to annoying. A Suggests is a possible compromise, and I did not deem it unacceptable. Hochachtungsvoll, Bernhard R. Link [1] or being able to dlopen it, for you nitpickers [2] well, dpkg is relatively good at it, but apt sucks. [3] though few data formats support this. [4] yes, I know, here people could start with "but bash is essential" just like in the post where I jumped into the thread last. [5] not yet, perhaps future perl will change that, but that does not matter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.ORG?
Moin, Raphael... On Mon, Apr 07, 2008 at 06:12:25PM -0500, Raphael Geissert wrote: > This is offtopic to your questions, but I should better say this now than > forgetting about this idea: > > For the new users registration process what about making mentors: > > * require the key to be in a keyserver so it can fetch it from there, and > removing the current 'upload your key' way. Good idea. Putting that on the todo list. > * and once the key has been imported in mentors' local keyring, the user > should fetch mentors' public key in order to send an encrypted message > either via web or via email to mentors in a format such as the following so > the new account is created: > Email: [EMAIL PROTECTED] > Password: foobar Sounds like the way Ubuntu verifies members' keys and in the process gets their "EULA" accepted. Yes, let's steal that idea. Thanks for your ideas. Christoph -- [EMAIL PROTECTED] www.workaround.org JID: [EMAIL PROTECTED] gpg key: 79CC6586 fingerprint: 9B26F48E6F2B0A3F7E33E6B7095E77C579CC6586 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.ORG?
On Mon, Apr 07, 2008 at 11:20:10PM +0200, Joerg Jaspert wrote: > On 11348 March 1977, Christoph Haas wrote: > > > The focus of mentors.debian.net is to host source packages that are > > supposed to be sponsored. So it's not some weird multiverse non-free > > binary warez repository or something. That doesn't ensure that some > > packages being uploaded can't be redistributed of course. But the same > > might happen with packages uploaded to ftp-master to be checked by the > > FTP team. > > Thats the reason why NEW packages aren't visible to anyone except > ftpteam members. Do you fear legal problems? Those packages are not officially available or endorsed by Debian. And since we threw away the uploaded binary packages on mentors.debian.net I haven't heard of anyone downloading those packages for their personal end-user use. I know that the binary packages were downloaded happily back then and users complained about the package quality. That made us think and so binary packages were not available any more. Fortunately most end-uses are not capable of building a binary package from a source package. :) > >> Are you hardcoded to your solution? I wouldn't have a problem if we go > >> and merge this into dak.ganneff.de > > > > Honestly dak scares me a lot. > > Its pretty simple. Then it must have changed a lot in the last years. Especially in terms of documentation. I'm willing to give it another look then. > dak is simple. Really. > Also, you wouldnt have to do the setup. I would have to deal with the setup for sure because it's the backend for the software we are running on. The repository structure on mentors.debian.net is accompanied by an SQL database contaning the meta information for example (although that's of course a matter of concept and not hewn in stone). Members can remove their own packages and comment on them for example. This is likely just not the focus of dak. > Well. I don't think you will get onto a debian.org machine in the near > (or distant) future. I offer you a way out, but it needs dak. :) I understand well that you prefer to join forces instead of re-inventing the wheel. But the repository handling code at mentors.debian.net is just a few KB of code. And since the "python-debian" package is around we can even drop half of that (back then there was no existing code in Python to parse control files for example). I assume that dak has more sophisticated features to deal with multiple distributions, different queues, override files etc. Thinking of mentors.debian.net we have one distribution, no (or one) queues, no override files but a sophisticated database and web system. The focus of mentors.debian.net is not background processing of package uploads like but giving uploaders control about their packages once they are uploaded. Discussion, commenting, rating, automated QA checks etc. Implementing a few features into dak might be a nice idea but it's a totally different beast IMHO. I don't refuse to get my hands dirty with dak. But the way you put it sounds like "screw your plans and enhance dak or good bye dot org". Bear with me but that sounds like it will stay dot net for while. I don't mind keeping the service running as dot net if it doesn't fit on dot org machines well. > Now, what does mentors do that dak doesnt? It might be interesting to > get that into dak too. The sum of what is already implemented and what is intended for the 'debexpo' software is documented at the Summer-of-Code proposal page [1] and the wiki page describing the result of the discussion on this list some time ago [2]. There is REVU and the PPAs and according to the discussion with many people there are prospects for a "simple" but comfortable and capable/pluggable software to publish packages on the web. Be it source and/or binary packages. Be it with or without automated QA checks. I would agree happily if we had a 90% intersection in dak and debexpo. But I fail to see that. Both just carry the "repository" stamp. Cheers Christoph [1] http://wiki.debian.org/SummerOfCode2008/debexpo [2] http://wiki.debian.org/DebianMentorsNet -- [EMAIL PROTECTED] www.workaround.org JID: [EMAIL PROTECTED] gpg key: 79CC6586 fingerprint: 9B26F48E6F2B0A3F7E33E6B7095E77C579CC6586 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Should -dev packages providing .pc files depend on pkg-config?
On Mon, Apr 07, 2008 at 06:49:24PM -0500, Manoj Srivastava wrote: > In this case, again, if my dev package requires a tool not in > build depends now, I should declare it, for the same reason -- the next > upload of the dev package might have different tools, or eliminate > tools -- and putting that build dependency in all the packages that > use my dev package is hard -- especially when we consider the cases > when the scenarios where these dependencies might change over time. But it's not the -dev package that uses the tool. It's the user of the -dev package that uses the tool so it should depend on it. For example, calls of pkg-config are hard-coded in the user of the -dev package, not in the -dev package itself. If a new -dev package requires different tools, then all users of the -dev package must be updated since they know nothing about the change and they will happily continue to call the old tool. Also, if it's the -dev package that depends on the tool and the tool changes, then the users will get worse error messages. Instead of a message like: Package foo was not found in the pkg-config search path. Perhaps you should add the directory containing `foo.pc' you'll get: pkg-config: No such file or directory OTOH if it's the user of the -dev package that depends on pkg-config, then you will always get a meaningful error message even if libfoo-dev stops providing a .pc file. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Should -dev packages providing .pc files depend on pkg-config?
On Tue, Apr 08, 2008 at 08:47:38AM +0100, Neil Williams wrote: > It's also a lot of packages - does such a dependency ever become > inferred by other packages? It probably shouldn't, for your reasons > above, so this would appear to be a case for a lintian check. > If ./configure exists and calls pkg-config or configure.in|ac calls > pkg-config or uses an m4 macro that calls pkg-config, the package should > build-depend on pkg-config ? (We don't seem to have many lintian checks > on Build-Depends.) Unfortunately that's not that easy since an autoconf-using package may build just fine if pkg-config is missing. pkg-config may only be needed for optional components that may not even be part of Debian. Only the maintainer can tell that pkg-config is required or not. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: Should -dev packages providing .pc files depend on pkg-config?
I demand that Gabor Gombas may or may not have written... [snip] > Also, if it's the -dev package that depends on the tool and the tool > changes, then the users will get worse error messages. Unless the -dev package has a wrapper for that tool, e.g. for backward compatibility reasons. xine-config in libxine-dev, for example, started using pkg-config; Depends is correct since everything which needs xine-lib uses xine-config (or at least I've not seen any which don't). [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES. There is news. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: piuparts testing of the archive
Lucas Nussbaum wrote: > > What needs to be done is: > - run installation/removal/purge tests for all packages > - run upgrade tests for all packages in etch > - make changes to piuparts to fix false positives or reduce the number > of failures by ignoring the less critical ones > - file all the bugs (many of those are RC) On log processing, what about doing a dependency-based log processing? so if package bar depends on foo, and foo fails to upgrade (or doesn't pass all the piuparts tests) it is very likely that bar will fail too, at least, because of foo. I think there was some tool around to build a dependency tree out of a Packages, so the main part of the log processing tool is already done. Cheers, Raphael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Adding lzma to dpkg's Pre-Depends
Hi, On Wed, 2008-04-02 at 14:01:16 +1000, Anthony Towns wrote: > On Tue, Apr 01, 2008 at 08:05:06AM +0300, Guillem Jover wrote: > > As per policy 3.5 I'm bringing this up here. I'd like to add lzma to > > dpkg's Pre-Depends, so that we can use lzma compressed packages after > > lenny w/o having to add an lzma Pre-Depends on each .deb package > > compressed that way. > > Hrm. Alternatively, the packages _do_ pre-depend on lzma though; and > you're aiming to avoid that by making lzma Essential:yes -- in the same > way packages that pre-depend on perl or bash don't need an explicit > dependency. Well not really Essential, it's going to be pulled like that yes, but other derivatives, might want to disable it. And I agree with Chris that it makes sense for dpkg to Pre-Depend on lzma as it's the one calling it, and that's an internal implementation detail, in case there's a liblzma in the future and we'd switch to using it, packages should not require to be changed. > libz and libbz2 are both included statically; Switching to dynamic linking is something I've been pondering for some time, but that's independent of this discussion, and something not to be changed at this point of the release anyway. > would it make more sense to do the same thing with the lzma (ie, > copy the binary into /usr/lib/dpkg), instead of making lzma > essential? The lzma package is tiny, it could be halved as I pointed out in the bug report (should probably just file bug reports on lzma for that). That would imply an installed size of about 150 KiB, 100 of those are just the lzma binary. In that case I don't really see the gain in having mostly the package there but w/o it being handled by the packaging system. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475116: ITP: asterisk-espeak -- eSpeak text-to-speech module for Asterisk
Package: wnpp Severity: wishlist Owner: Andrew Pollock <[EMAIL PROTECTED]> * Package name: asterisk-espeak Version : 0.4 Upstream Author : Francois Aucamp <[EMAIL PROTECTED]> * URL : https://sourceforge.net/projects/asterisk-espeak * License : GPL Programming Lang: C Description : eSpeak text-to-speech module for Asterisk This package provides the "eSpeak" dialplan application, which allows you to use the eSpeak TTS Engine with Asterisk. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
