Bug#477125: ITP: bugs-everywhere -- distributed bug tracker
Package: wnpp Severity: wishlist Owner: Ben Finney <[EMAIL PROTECTED]> * Package name: bugs-everywhere Version : 0.0.193 Upstream Author : Chris Ball <[EMAIL PROTECTED]> * URL : http://bugseverywhere.org/ * License : GPL 2+ Programming Lang: Python Description : distributed bug tracker Bugs Everywhere is a “distributed bug tracker”, designed to complement distributed version control systems. By using a distributed VCS as a back-end for bug state, it gains several convenient features: . * Bugs and code that live on branches are tracked together. * Users can fully modify bug state while offline. * When a user checks out a project’s source code, she gets the current bug state for free. * A web interface to the bug database becomes just another client that merges with the main repository.
Re: Bug#475971: This is caused by LDFLAGS being set in the environment (by dpkg-buildpacakge)
Le dimanche 20 avril 2008 à 21:00 +0200, Adeodato Simó a écrit : > Python's distutils honour LDFLAGS, and when building the python > extension passes -z,defs to the linker, and the build obviously bombs. > > I guess the solution is to accept LDFLAGS is to be exported, and to make > the part that builds python be robust against that. In all cases you should not use -z defs to link a python module, because there will be unresolved symbols in it. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: separate package for iotop?
On Mon, Apr 21, 2008 at 11:54 AM, Steve Greenland <[EMAIL PROTECTED]> wrote: > On 20-Apr-08, 16:33 (CDT), Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > > In article <[EMAIL PROTECTED]> you wrote: > > >> I'm not sure if it warrants its own package or if there is another > > >> package it should be added to. > > >> > > >> Any thoughts? > > > > > > Perhaps along with top in procps? > > > > The python dependency should not be introduced - so if we dont have a > python > > based system management package, it might be good to start one. > > But it could be a Suggests, since it's only one of several utilities in > the package. Craig, do you think including the iotop python script in procps is a good idea or should I create a separate package for it. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation
Hi Patrick, Patrick Ringl [2008-04-21 3:46 +0200]: > I am concerned about 'cupsddk' which recently passed NEW. On 25th of > march I contacted pkg-cups for joining the team and working on cupsddk > [1] since I am about to repackage 'splix' (a driver for samsung laser > printers). > Martin Pitt did not accept my request for NO reason and told me to work > together with the Ubuntumaintainer of the package. What? I was happy to see someone working on those in Debian and welcomed you to join [1][2]. That hasn't changed, and I did not refuse your request at all. I merely suggested that someone else already packaged those, and it would make sense to look at the existing package rather than doing everything from scratch again. Where did I write that I refused your request?? Martin, who is slightly confused and thinks that there is a big misunderstanding happening here [1] http://lists.alioth.debian.org/pipermail/pkg-cups-devel/2008-March/005104.html [2] http://lists.alioth.debian.org/pipermail/pkg-cups-devel/2008-March/005110.html -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: Should -dev packages providing .pc files depend on pkg-config?
On Wed, Apr 16, 2008 at 10:58:47PM +0100, Neil Williams wrote: > On Wed, 2008-04-16 at 22:12 +0200, Jakob Bohm wrote: > > On Wed, Apr 16, 2008 at 04:12:45PM +0200, Gabor Gombas wrote: > > > On Wed, Apr 16, 2008 at 11:23:51AM +0100, Neil Williams wrote: > > > > > > > What about these clauses as a Policy amendment? > > > > > > > > 1. If a library *only supports the retrieval of FOO_LIBS and / or > > > > FOO_CFLAGS by the use of pkg-config*, pkg-config becomes part of the API > > > > of that library and the -dev package of that library must depend on > > > > pkg-config. The mere presence of a .pc file in the -dev package of the > > > > library does *not* mean that only pkg-config is supported. e.g. where a > > > > library requires the use of an m4 macro that involves calling > > > > pkg-config, this would require the -dev package to depend on pkg-config > > > > but if a library provides a .pc file but also supports alternative > > > > method(s), the -dev package does not need to depend on pkg-config. > > > > > > > > 2. If a source package uses libraries that package a .pc but where all > > > > the libraries also support other methods of obtaining the relevant data, > > > > and the source package requires the use of pkg-config despite those > > > > other methods being available, then that choice by the source package > > > > upstream must result in a Build-Depends on pkg-config in the source > > > > package. > > > > > > > > Is that suitable as a Policy clause? (probably needs a few tweaks for > > > > clarity and examples in clause 1). > > > > > > Wow, that's awfully complicated. This is much more straightforward: > > > > > > "If a package wants to call /usr/bin/foo during build and fails > > > to build properly if /usr/bin/foo is not present, then the > > > package MUST Build-Depend: on some other package providing > > > /usr/bin/foo". > > > > > > And by this definition, it is the package _invoking_ pkg-config that > > > should Build-Depend on it, not the package that happens to ship a .pc > > > file. > > > > > > > Here is another example supporting Gabor's proposal over Neil's: > > > > Package libfoo-dev version 1.0.4 only documents how to use libfoo via > > pkg-config. Package bar build-depends on libfoo-dev >= 1.0.4 and uses > > pkg-config to locate libfoo.so.1 etc. Under Neil's rules, libfoo-dev would > > Depends: pkg-config, bar would not Build-Depends: pkg-config. Under Gabor's > > rules, bar would Build-Depend pkg-config, but libfoo-dev would only > > Recommends: pkg-config. > > No - bar would Build-Depends: pkg-config because it contains > a ./configure script that calls pkg-config - that's why some duplication > will always occur, precisely to prevent these failures. A duplicate > depends is not a problem. > > Your example states: "bar uses pkg-config to locate libfoo.so.1" - bar > calls pkg-config so it must depend on it - in this case Build-Depends:. > > That was the result of an over-zealous edit of the clauses. Sorry. > > ???0 If a source package calls pkg-config directly, it must Build-Depend > on pkg-config. > > > > > 2. If a source package uses libraries that package a .pc but where all > > > > the libraries also support other methods of obtaining the relevant data, > > > > and the source package requires the use of pkg-config despite those > > > > other methods being available, then that choice by the source package > > > > upstream must result in a Build-Depends on pkg-config in the source > > > > package. > > From another message: > > If we stick with the idea of "you call it, you depend on it", these > situations become a lot clearer. > > If foo-config changes internally to not call pkg-config anymore, that > allows the -dev to drop the pkg-config dependency. What is wrong, > therefore, is for the package using foo-config to expect that the -dev > continues to provide pkg-config and to then use pkg-config itself for > other things *without* a dependency. > > i.e. a duplicate dependency is the best approach here. > > > However just to clarify on some other examples elsewhere in this thread, > > the following rules may need to be added: > > > >2. If libfoo-dev contains scripts which would typically be called by > > packages that Depend, Pre-Depend or Build-Depend on libfoo-dev, then > > anything needed by those scripts should (RFC-should) be ordinary > > Depends for the libfoo-dev package. For instance if programs building > > against libfoo would typically call /usr/bin/foo-config-get, then > > anything called by foo-config-get (such as pkg-config or perl) would > > need to be listed as Depends for libfoo-dev. Note that this does not > > extend to anything otherwise needed by callers to take advantage of > > files in libfoo-dev. For instance the presence of .h files in > > libfoo-dev does not imply a Depends: c-compiler, nor would .pc files > > imply a Depends: pkg-config. > > > >3. Similarly, the f
Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation
> Patrick Ringl [2008-04-21 3:46 +0200]: > > I am concerned about 'cupsddk' which recently passed NEW. On 25th of > > march I contacted pkg-cups for joining the team and working on cupsddk > > [1] since I am about to repackage 'splix' (a driver for samsung laser > > printers). > > Martin Pitt did not accept my request for NO reason and told me to work > > together with the Ubuntumaintainer of the package. Patrick, Maintenance of cupsddk is open for team contributions, please pass any changes you have to the mailing list [EMAIL PROTECTED] and we will incorporate them. http://svn.debian.org/wsvn/pkg-hpijs/cupsddk/?op=log We also need cupsddk to fix some release critical bugs in hplip, which is why we have packaged it. We work with Till in the hplip team as well and he has commit access, so it seemed like the next most sensible place. http://lists.debian.org/debian-printing/2008/02/msg00043.html You didn't change the RFP to an ITP and the WNPP is full of people who haven't issued an ITP and say they will but then never do anything. Policy states you should change the WNPP bug to ITP, which you didn't, so there has been no policy violation. But you are free to assist with the package in what ever way you can. All contributions are welcome. cupsddk has been uploaded to NEW twice and updates since, so you could of said anything at any time. There have also been some bug reports, so please forward any comments you have on the copyright file etc... Perhaps in the longer term we could consolidate in a debian printing team, http://lists.debian.org/debian-printing/ but given the amount of work (outstanding BTS) each team has any contributions are welcome. Mark signature.asc Description: This is a digitally signed message part.
Re: Should -dev packages providing .pc files depend on pkg-config?
On Fri, Apr 18, 2008 at 02:09:40PM -0500, Manoj Srivastava wrote: > I would say they are making it very inconvenient, but still not > forcing you. Push comes to shove, you can still build depend on a > specific version, and use an explicit -L. That is correct, of course. But if you're using a versioned depends just because you're unwilling to use what the library packager considers the appropriate way to link, your package deserves a bug IMO. ;-) > Yes, it means you have to track where upstream puts stuff, and > manually upgrade. Yes, it is more prone to error. Yes, using pkg-config > is _convenient_. Yews, it is probably advisable to use pkg-config. But > not mandatory. If Debian's library maintainer says that this is the only way to link the library, then IMO it is in fact mandatory. Note that I can't think of many practical situations where a libarary maintainer should be allowed to say such a thing IMO. :-) > I still think if your ./debian/rules calls a program, and that > is not in Build-essential; it is your responsibility to arrange for it > to be available using a build dependency. Yes, on that we agree, we only seem to have an academic disagreement about concepts[1]. :-) Thanks, Bas [1] Previously, I hadn't made up my mind, and I was open to the possibility of needing pkg-config as a Build-Depends in the -dev package. I have now decided that it doesn't belong there (except when it is called by a script from that package). -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Should -dev packages providing .pc files depend on pkg-config?
On Thu, Apr 17, 2008 at 12:54:32PM +0200, Gabor Gombas wrote: > On Thu, Apr 17, 2008 at 12:02:20PM +0200, Bas Wijnen wrote: > > > How is this different with _any_ dependency on the system? Do you > > suggest that iceweasel should drop its libgtk dependency, because users > > might want to use their own compiled version of it? > > iceweasel _uses_ libgtk. A -dev package that ships a .pc file does _not_ > use pkg-config - it just provides a data file that pkg-config (or some > other similar tool) can use. There seems to be a misunderstanding. I was talking about this statement: > > What if the library says "You must call /usr/bin/foo during build"? > > But the library can't say "foo must come from a Debian package". What > if I have my local replacement? Why should I be forced to install a > package that is now useless for me (and installing it would only cause > confusion as there are now two different tools with the same name > present in $PATH)? I was assuming that /usr/bin/foo would be supplied by the -dev package, and that the library documentation mandates its use to anyone who wants to link with the library. If /usr/bin/foo needs a program (such as pkg-config) to do its work, is it the caller's, or the -dev package's responsibility to [Build-]Depend on that program? IMO the -dev package should have a Depends, since the caller doesn't (want to) know how /usr/bin/foo does its magic, so it cannot get it right. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation
Hello Martin, Martin Pitt wrote: Hi Patrick, Patrick Ringl [2008-04-21 3:46 +0200]: I am concerned about 'cupsddk' which recently passed NEW. On 25th of march I contacted pkg-cups for joining the team and working on cupsddk [1] since I am about to repackage 'splix' (a driver for samsung laser printers). Martin Pitt did not accept my request for NO reason and told me to work together with the Ubuntumaintainer of the package. What? I was happy to see someone working on those in Debian and welcomed you to join [1][2]. That hasn't changed, and I did not refuse your request at all. I merely suggested that someone else already packaged those, and it would make sense to look at the existing package rather than doing everything from scratch again. Where did I write that I refused your request?? You have not _explicitely refused it - but you didnt add me either. If you did in the first place I would have used Alioth's SVN repo tho. And to be honest - or rathe rin fact it does NOT make any sense, since the Ubuntupackage is more of a hack than a debian-like package - and even the one that just passed NEW is just the Ubuntupackage with some of the lintian-warnings fixed. Martin, who is slightly confused and thinks that there is a big misunderstanding happening here [1] http://lists.alioth.debian.org/pipermail/pkg-cups-devel/2008-March/005104.html [2] http://lists.alioth.debian.org/pipermail/pkg-cups-devel/2008-March/005110.html Could be that I have been a bit harsh in the first place, but I was disappointed and angry and felt of ignored by you in some way. regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation
Mark Purcell schrieb: Patrick Ringl [2008-04-21 3:46 +0200]: I am concerned about 'cupsddk' which recently passed NEW. On 25th of march I contacted pkg-cups for joining the team and working on cupsddk [1] since I am about to repackage 'splix' (a driver for samsung laser printers). Martin Pitt did not accept my request for NO reason and told me to work together with the Ubuntumaintainer of the package. Patrick, Maintenance of cupsddk is open for team contributions, please pass any changes you have to the mailing list [EMAIL PROTECTED] and we will incorporate them. http://svn.debian.org/wsvn/pkg-hpijs/cupsddk/?op=log We also need cupsddk to fix some release critical bugs in hplip, which is why we have packaged it. We work with Till in the hplip team as well and he has commit access, so it seemed like the next most sensible place. http://lists.debian.org/debian-printing/2008/02/msg00043.html Well that is true, but uploading a package that WILL be release-critical is any good? And yes since the copyright file is wrong, this is a rc-bug. And well, since it is cups related, I'd like to see it in pkg-cups tho. I doubt that my changes are 'accepted' by Till, since they'll turn the package inside out - but I'll give it a try. Till did never deal with my correspondence so far, which is why I think he should not maintain it - apart from that I am a CDBS fan, and things look far cleaner than with his debian/rules. You didn't change the RFP to an ITP and the WNPP is full of people who haven't issued an ITP and say they will but then never do anything. Policy states you should change the WNPP bug to ITP, which you didn't, so there has been no policy violation. But you are free to assist with the package in what ever way you can. All contributions are welcome. Yes, you are right. Although I maintain several packages, I forgot about filing the ITP. My hint of a proper policy violation was anot about that 'act of stealing' but rather because it keeps the wrong copyright file :-) cupsddk has been uploaded to NEW twice and updates since, so you could of said anything at any time. There have also been some bug reports, so please forward any comments you have on the copyright file etc... Yep, unfortunately I have not noticed it's upload to SID in the first place - but I'll try to contribute :-) Perhaps in the longer term we could consolidate in a debian printing team, http://lists.debian.org/debian-printing/ but given the amount of work (outstanding BTS) each team has any contributions are welcome. Mark regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation
Hi Patrick, Patrick [2008-04-21 17:55 +0200]: > You have not _explicitely refused it - but you didnt add me either. Oh, that might have been the point of confusion. I am an administrator for the cupsys package alioth project, but you didn't state that you wanted to work on cupsys itself (and, besides, you should do some contributions before you get commit access). So far I assumed that there would be separate projects for separate sources? > And to be honest - or rathe rin fact it does NOT make any sense, since > the Ubuntupackage is more of a hack than a debian-like package That might very well be so, I haven't checked it at all. I just wanted to ensure that you are aware of it. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation
[removing non-related maillists and recipients, this is a purely devel comment] Patrick wrote: > Till did never deal with my correspondence so far, which is why I think > he should not maintain it - apart from that I am a CDBS fan, and things > look far cleaner than with his debian/rules. A bit of - hopefully constructive - nit-picking: Just because a rules file with CDBS *looks* clean that doesn't necessarily imply any direct improvement in package quality. I'm playing devil's advocate here because I also use CDBS in many of my packages, but I still think it's important to keep the distinction in mind. Cheers -- Leo "costela" Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: elegant ways to build a package two times
On Apr 15, Josselin Mouette <[EMAIL PROTECTED]> wrote: > You don???t need automake for this to work, it???s just that automake does > things right by default. Fixing the package to get out-of-tree builds to > work using VPATH should be feasible. Can you point me to a good example of a package using VPATH? > Otherwise, the least inelegant way is probably, as already suggested, to > copy the full sources in a subdirectory. Actually both ways share the same problem: a lot of code will have to be duplicated in debian/rules (maybe I should try using "define" to create macros). -- ciao, Marco signature.asc Description: Digital signature
Re: RFH: Multiarch capable toolchain as release goal
Kevin Mark wrote: > On Sun, Apr 20, 2008 at 09:06:15PM +0100, Roger Leigh wrote: >> Robert Millan <[EMAIL PROTECTED]> writes: >> >>> On Sun, Apr 20, 2008 at 05:28:23PM +0200, Bernd Zeimetz wrote: >> If you do want to wait for permission/refusal, you might find you >> never get a reply and end up waiting forever. So, why not wait long >> enough for a reply, say a fortnight, and then go ahead and hijack it >> after that if you have no response (and tell them in the mail that >> this is what you will do). > Is there a guideline or policy for such hard-to-reach Developers with > regard to hi-jacking or NMU? There is a guideline for doing NMUs which kind of includes this case in the Developer's Reference... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation
On Mon, Apr 21, 2008 at 10:36:37PM +1000, Mark Purcell wrote: > But you are free to assist with the package in what ever > way you can. All contributions are welcome. Patrick, as you see you are clearly welcome. So please cool down and submit patches :) > Perhaps in the longer term we could consolidate in a debian printing team, > http://lists.debian.org/debian-printing/ but given the amount of work > (outstanding BTS) each team has any contributions are welcome. Certainly, a package called "cupsddk" ending up maintained by hplip team is quite suprising.. -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477218: ITP: estron -- data-centric development interpreter for GNOME
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: estron Version: 0.7.0 Upstream Authors: Neil Williams, Linas Vepstas URL: http://estron.alioth.debian.org/ License: LGPL Description: data-centric development interpreter for GNOME estron supports the creation of data-driven graphic interfaces based on the structure of the data, not a programming language. estron interface files are written in XML and declare an interface between the datasource and a graphic interface, currently Glade. Interfaces are designed, improved and operated at runtime. Other GUI design tools could also be supported. Estron - the new name for DWI, Data with Integration - is a fairly simple environment for quickly creating data-driven applications, that is, graphical applications that manipulate and show info from a database. This environment differs from others in that it is focused on native GTK/Gnome support through the Glade GUI designer, and thus allows you to build user interfaces as elegant as you can make them in Glade. Multiple SQL database vendors are supported through ODBC or libdbi drivers. There is a simple db-driver infrastructure so its easy to support for additional SQL API's. estron is also related to QOF and the two engines work together so that estron applications can also access QOF data sources like QSF XML, sqlite0 and libgda3 (awaiting completion in libqof2). estron can be the glue between various data sources, providing a common means of accessing user data, calculating intermediate data and exporting results in a variety of formats. estron allows users to design, improve and operate estron interfaces without recompilation. At all stages, the interface is determined by the structure of the data, not the limitations or complexity of a programming language. I've restarted upstream development with help from Linas - the use of Alioth is purely for easier upstream development, estron is not a native Debian package. Expected binary packages: estron (runtime interpreter), estron-examples, libestron0, libestron-dev, libestron-dbg and libestron-doc (libestron API). The -dev is only needed when developing applications to export estron files or interface directly with libestron0 during other operations. Applications written in estron only need the runtime interpreter. My expectation is that quicklist will be one of the current applications to gain estron export support, providing a simple GUI for creating estron files (which currently need to be created manually). A full WYSIWYG estron GUI is also possible. Some issues remain to be resolved upstream before the 0.7.0 release is made (removing some deprecated Gtk code mainly). If anyone wants to see estron available in Lenny (or help make that happen), let me know. Otherwise, I expect to release and upload estron 0.7.0 alongside libqof2 0.8.0 after Lenny. The current code is in Debian SVN (link on the alioth homepage) if anyone wants to try it. (I can prepare a version in experimental if requested.) -- 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
Request Application for Mentoring my Academic Final Year Project.
Respected Sir, I would like to (just for the sake of reference) highlight myself. I had applied for GOC2008 earlier last month for an project on File System. Actually this was the very first time I have been participating into any of such event. Due to any reasons my application was rejected. I would be very much pleased if i get to know where i was weak and what made me fail. As it was the very first time not taking this up hard, I will practice more. But I would like to ask you if there is any way that you can help me doing my *Final Year Project*. I mean to say that can you *sponsor* us our Final Year Project which I again wish to do in the field *related to File Systems*. Then whatever may be your requirement I promise you that I will fulfill all the needs that you expect from the code written by us. Actually by us i mean to say that our final year project consists of *5 - 6 members* who working together complete the project during the *Final Year of the Degree Course*(1 Year Duration). I was thinking to do something which can enhance our skills into the core computer science implementation. So i would like to implement the IDEAS proposed into the papers given at the links below. *http://www.fsl.cs.sunysb.edu/project-antivirusfs.html* I would be pleased to provide any More Details may be it about us or about the project Waiting for your Response and Help in this regard. Thank You for Spending Your Valuable Time For us. Yours only Suraj R. Biyani **(SRB)** "Human will never devise an invention more beautiful, more simple or more direct than does nature because in her inventions nothing is lacking, and nothing is superfluous"
Re: separate package for iotop?
Hi Paul, thanks for bringing iotop to my attention! On Monday 21 April 2008 13:13, Paul Wise wrote: > Craig, do you think including the iotop python script in procps is a > good idea or should I create a separate package for it. moreutils might also be an option, it would also be a new dependency, but at least it's optional. regards, Holger pgpeAUQRCttzS.pgp Description: PGP signature
Re: [pkg-boost-devel] Bug#473752: Bug#473752: Boost 1.35 has been released
On Sat, Apr 19, 2008 at 10:53:35PM +0200, Olaf van der Spek wrote: > Steve M. Robbins wrote: >> If we do decide to have co-installable -dev packages, the next >> question is how do we handle the current non-versioned includes and >> link libraries? Do we follow what gcc and python do, providing a >> defaults that change from time to time? Or should we not attempt to >> provide such defaults? I fear the first option will bring us back to >> the same misery we currently suffer with transitions. So I'm fine >> with not providing defaults, which is in line with upstream practices >> anyway. > > What would that imply? > Would users have to modify the build script to add the Boost include > directory to the include path? Likely, yes. > At the moment this is not necessary and I think requiring it is a bad > idea (for users that have to compile third-party code) Noted. On the other hand, some might like the flexibility of deciding which Boost version to build with, similar to the ability to choose between Qt3 and Qt4. >> I also removed the Boost library version from the link library names. >> However, reflecting upon what you say, I suppose we really prefer to >> have version X-dev and version (X+1)-dev co-installable. If so, we >> would revert that change and adjust the rules accordingly. > > Is there documentation about the incompatibilities between 1.34 and 1.35? No, not that I'm aware of. Chimo, -Steve signature.asc Description: Digital signature
