On Wed, Jun 25, 2014 at 3:58 AM, Matthias Klose <d...@debian.org> wrote:
> Am 25.06.2014 00:51, schrieb Ben Longbons:
>> On Tue, Jun 24, 2014 at 3:08 PM, Matthias Klose <d...@debian.org> wrote:
>>> Control: reopen -1
>>>
>>> so this is a very generic claim ("breaks everything") without giving any
>>> concrete package.
>>
>> It doesn't matter that it's not in a package.
>>
>> A debugger that can only be used to debug packages that are already
>> part of the distro (and should, in theory, be bug-free) is completely
>> useless to users. If this is your intent, please rename the package
>> and executable to 'gdb-debian' with a note that it is only intended to
>> be used to debug Debian packages.
>
> this already exists. it is called gdb-minimal.
>
>> The burden of proof that python3 is beneficial for the gdb package is
>> on you, and bug 727003 didn't even have a "very generic claim".
>>
>>> Are you aware of other pretty printers not
>>> working with python3?
>> From what I've seen, pretty printers that *do* work with python3 are a
>> very small minority.
>
> so for now the majority of pretty printers in Debian, afaics all of them, are
> able to use python3.As the other message showed, this claim was not true when you made it. The impact of your packaging decisions is larger than you appear to realize. And golang-src is a great example of a case where Debian is currently *failing* to ship python pretty-printers in the binary version of a package. Is there an equivalent to CONTENTS but for source packages? If a python3-only gdb is desirable, the only sane migration strategy that I can think of is: - For jessie, ship gdb-python2 and gdb-python3 (since python3 is more likely to have bugs, it should probably be the default, but switching back to python2 and at any given moment is *absolutely* essential) - For jessie+1, consider shipping only gdb-python3 (if that still seems like a good idea, and there are no more migration problems that have appeared) That's an actual migration strategy, unlike "just flip the switch and if it breaks anybody's software, say it's their fault for being incompatible with something that didn't even exist at the time it was created". IMO it is quite reasonable to have production use Debian stable, while development happens on a newer distro, such as Debian testing. Personally, what I gain most from it is the ability to test my code with newer versions of tools. Public testing, of course, happens on the same platform as production. Are you trying to make the claim that people shouldn't use platforms other than Debian stable to develop software? Because (as someone who write a lot of python) it is *far* from trivial to make python code work *properly* on both python2 and python3. Please, don't make my life more complicated than it needs to be for no reason at all. > So as a step forward it would be good if you could name your software and > provide a pointer to the sources. Same for other software which only seem to > be > mentioned in blog posts. The particular software I maintain https://github.com/themanaworld/tmwa which is a server used by the 'manaplus' package. Although I have done a lot to make the code *itself* packagable, the ecosystem (rapid releases of code and implicitly paired data, which both become obsolete rather quickly) is not very suitable for a distro that does stable releases. And even if it was, the popcon of people running a server would be much lower than the number of people using the client to *connect* to a server. My pretty printers were simple enough, and do little enough string manipulation (you *cannot* assume that inferior strings have a known encoding - python2's narrow strings always work, python3's wide strings will not (and the best method of dealing with that, 'surrogateescape', is not available in python2)), that I managed to make them compatible with python3 (at the cost of performance, of course), but I am very upset that you think I will never need to hunt down regressions in old versions (as in, a couple months old - it's okay if 3 years old version of my software breaks, I've probably caught all the bugs by then) of my software, which I cannot do with a python3-only gdb. Don't get me wrong - I love python3 for writing new software - but the lack of a reasonable migration strategy means that python2 and its "libraries" (which in this sense includes gdb) *must* be maintained for old code, and old code *cannot* be assumed to just go away. Progress is important (not that there have been any claims that this is actually progress), but that's not an excuse to make people's lives needlessly difficult just because you're in charge of something important and you have the *power* to do it. I'm spending *way* too much of my time telling people this. > > thanks, Matthias > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
