debian package (to be orphaned)

[Sergey Kirpichev]

Hello,

I'll stop maintain the debian sympy package too. Is there anyone interested in supporting this?

Package now is in the debian-science repo:
http://anonscm.debian.org/cgit/debian-science/packages/sympy.git/
In the NEW queue there is an upload, that fixes all reported debian bugs:
https://ftp-master.debian.org/new/sympy_0.7.5-4.html
So, I think, it's in a good shape. And it should be trivial to update this to a new upstream version.

[Joachim Durchholz]

Am 20.01.2015 um 13:21 schrieb Sergey Kirpichev:
> Hello,
>
> I'll stop maintain the debian sympy package too.

Thanks for letting us know.

> Is there anyone interested in supporting this?

What are the benefits of having SymPy in a distro package?
One that I can think of is easier installation; are the others?
The downside I see is people are installing older versions and increase
our workload of support requests; are the advantages worth it?

Regards,
Jo

[Ondřej Čertík]

Hi,

Thanks Sergey for maintaining it. I created the initial Debian
package, and now I am a Debian Developer, so I can upload it myself.
The advantage of having it in Debian is that any Debian or Ubuntu user
can easily install it using the native package manager. Extremely
useful.

Ondrej

[Sergey Kirpichev]

On Tuesday, January 20, 2015 at 6:51:48 PM UTC+3, Ondřej Čertík wrote:

Thanks Sergey for maintaining it. I created the initial Debian
package, and now I am a Debian Developer, so I can upload it myself.

Good news.

I think, you are member of the debian science team, so there no problems to access the repo.
But it's also possible now to use single repo (i.e. github's) to keep both master branch
and stuff for debian's work (debian, upstream, pristine-tar branches):
https://wiki.debian.org/PackagingWithGit?highlight=%28\bCategoryGit\b%29#Using_the_upstream_repo

[Ondřej Čertík]

Exactly, that's the best I think. I know the Python Modules Packaging
Team is using svn, which is a big pain.

Ondrej

[Sergey B Kirpichev]

On Tue, Jan 20, 2015 at 12:01:27PM -0700, Ondřej Čertík wrote:
> > I think, you are member of the debian science team, so there no problems to

> > access the repo. [...]

>
> Exactly, that's the best I think. I know the Python Modules Packaging
> Team is using svn, which is a big pain.

To be clear: the current package is in the Debian Science team
repo (actually, svn is the reason why is this). It could be apparent
from my first post (it has git url) and should be clear from the second...

[Ondřej Čertík]

Yes, I understood --- thanks for moving it there!

Ondrej

[Aaron Meurer]

It looks like the SymPy debian package has some strange recommended dependencies (http://stackoverflow.com/questions/28135571/installing-python-sympy-in-a-docker-image). Might be worth cleaning these up. 

Aaron Meurer

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CADDwiVDdG%2BcjZybzPmb2W17_53Frie16BobWC%2B0ERk8n4gGQVw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Sergey B Kirpichev]

On Wed, Jan 28, 2015 at 12:38:04PM -0600, Aaron Meurer wrote:
> It looks like the SymPy debian package has some strange recommended
> dependencies

> ([1]http://stackoverflow.com/questions/28135571/installing-python-sympy-in-a-docker-image).

> Might be worth cleaning these up. 

Fonts here are for reasons, see changelog:
https://bugs.launchpad.net/ubuntu/+source/sympy/+bug/742658

However, Suggests header may be more appropriate here (default - not
consider as a dependency for installing). But preview function will not work.

[Aaron Meurer]

What is the Debian policy? If a single function uses something is it a recommended dependency? Imaging is another one. It looks like it is only used by the pyglet plotting (and pyglet is not on that list). And there are quite a few libraries that some parts of SymPy can interface with that aren't on that list either (e.g., should it include a whole compiler toolchain for the code generation?).

I'll let you Debian guys figure this stuff out. I just wanted to point it out.

Aaron Meurer

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/20150128191328.GA24397%40darkstar.order.hcn-strela.ru.

[Joachim Durchholz]

Am 28.01.2015 um 20:48 schrieb Aaron Meurer:
> What is the Debian policy? If a single function uses something is it a
> recommended dependency? Imaging is another one. It looks like it is only
> used by the pyglet plotting (and pyglet is not on that list). And there are
> quite a few libraries that some parts of SymPy can interface with that
> aren't on that list either (e.g., should it include a whole compiler
> toolchain for the code generation?).
>
> I'll let you Debian guys figure this stuff out. I just wanted to point it
> out.

(Full disclosure: I'm just a user of a Debian-based distro, not a
maintainer; I have a rough idea what maintainers do, but that's all. The
package structure outlined below is the one that would give me the most
useful and straightforward set of options. I generally found
optional/recommended dependencies awkward because they don't go away
automatically when the main package is uninstalled; instead, they need
to be removed explicitly.)

Policy is that if it's a function that users would expect, it should be
"depends", if it's a function users would expect to not work without the
package, it's "recommends".
Which hinges on that vague notion of "what users expect".

One way out is to have a separate package for each usage scenario, such
as (very roughly, and not necessarily the best set of splits):
- sympy-base ("this is the base package; you'll usually want
sympy-terminal and/or sympy-plot")
- sympy-terminal ("this uses UTF-8 fonts to properly display formulae on
the terminal, and pulls in any needed fonts")
- sympy-plot ("for creating function plots").

On specialty package structure, e.g. sympy-plot:
First, it would depend on sympy-base and pyglet (I'm assuming plotting
needs just pyglet, it could be more).
Optionally, the package maintainer could take those sympy packages in
sympy-base that are just for plotting, and move these over to sympy-plot.

Just my 2c.

[Sergey Kirpichev]

On Wednesday, January 28, 2015 at 10:48:25 PM UTC+3, Aaron Meurer wrote:

What is the Debian policy?

https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
 

If a single function uses something is it a recommended dependency?

It depends on how important this function is for your users.

[Sergey Kirpichev]

On Thursday, January 29, 2015 at 12:34:08 AM UTC+3, Joachim Durchholz wrote:

Policy is that if it's a function that users would expect, it should be "depends"

No, policy is not about this.  Don't misguide people, please.  Read the documentation.

[Matthew Brett]

Hi,

Do you mean this :
https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html#s-depends
?

"""
Package A depends on Package B if B absolutely must be installed in
order to run A. In some cases, A depends not only on B, but on a
version of B. In this case, the version dependency is usually a lower
limit, in the sense that A depends on any version of B more recent
than some specified version.

Package A recommends Package B, if the package maintainer judges that
most users would not want A without also having the functionality
provided by B.

Package A suggests Package B if B contains files that are related to
(and usually enhance) the functionality of A.
"""

Is there is anything that gives much more detail?

Cheers,

Matthew

[Sergey B Kirpichev]

On Wed, Jan 28, 2015 at 03:38:15PM -0800, Matthew Brett wrote:
> Do you mean this :
> https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html#s-depends

Yes. I gave the policy reference in another reply (actually, this
faq entry has this reference too).

> Is there is anything that gives much more detail?

I don't think there is something to be explained. The Debian
Policy (and so your faq entry) - very clear about recommends vs
suggests. This distinction is in some sense - subjective (on another
hand, depends field is not).

[Joachim Durchholz]

Why did you ignore the disclaimer, Sergey?

[Joachim Durchholz]

That's what I said, essentially.
Please clarify where I went wrong.

[Sergey Kirpichev]

On Thu, Jan 29, 2015 at 11:33 AM, Joachim Durchholz <j...@durchholz.org> wrote:
> Please clarify where I went wrong.

I did.

[Aaron Meurer]

Guys please stop. Unless you plan on maintaining the Debian package (which I believe Ondrej has volunteered to do), there is nothing else to say here.

Aaron Meurer

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/20150129112650.GA28421%40darkstar.order.hcn-strela.ru.

[Joachim Durchholz]

Am 29.01.2015 um 17:59 schrieb Aaron Meurer:
> Guys please stop.

tl;dr: I feel I need to quit from SymPy to stop this from happening again.
My latest ongoing work is on https://github.com/sympy/sympy/pull/8909 ,
feel free to take over.

Longer version
==============

Why quit?
---------

Here's the list of choices that I have been mulling over in the past few
hours:

A) Non-action.
Except this pattern is going to repeat: I'm stepping anywhere Sergey has
a vested interest in, he's going passive-aggressive on me, I'm going
"raaagh!" on him, we're getting calls to order, I'm getting more frustrated.
Also, having to tip-toe around his vested interests is going to feel so
restrictive to me that I'm going to be unhappy about *that*.
Not going to work in the long term.

B) Argue to the arbiters into sanctioning Sergey more so that he stops
his passive aggression.
Except I never wanted to be the kind of person who argues anybody into
anything.

C) Put up the "him or me" choice again.
This is even worse than (B). I still feel bad about having done it once.
So... not going to do that a second time.

D) Avoid having to do with him - i.e. quit.
Option D1: Quit silently - nah, that leaves people unclear about why I
fall silent.
Option D2: Quit while explaining in detail how bad Sergey really is.
Well, he is, but that's not going to be news to anybody; besides, who am
I to teach others.
Option D3: Quit explaining my options, be as neutral and matter-of-fact
as possible.

All choices are clearly bad, except D3 which is merely sad, so D3 it is.


Handing over ongoing work
-------------------------

I have a reworked and 80% done version of bin/diagnose_imports sitting
on my disk.
It's in a non-working, half-finished state right now, which is a pity
because that makes it hard to start work on for anybody else, but I'm
feeling too frustrated to put any more effort into it.
So... for what it's worth... take a look at PR #8909 if there's any
interest in it, and close and forget it if not.


Parting words
-------------

I'm saying Good Bye, and wish SymPy and everybody involved all the best.

I have learned a lot, and maybe I have helped others in some ways, so I
don't feel I wasted time.

I guess I have to move on.

Regards,
Jo

[Sergey Kirpichev]

On Friday, January 30, 2015 at 6:37:11 AM UTC+3, Joachim Durchholz wrote:

B) Argue to the arbiters into sanctioning Sergey more so that he stops
his passive aggression.

They can't do more, I'm not part of this project.  But Aaron, maybe you can
remove me from whitelist for this maillist too?  (I don't think this will add too much
work for moderators...)
 

C) Put up the "him or me" choice again.

No such choice at all is possible, I'm not involved into sympy.  The reason
I responded here - I was subscribed on this conversation before.

Stop this insanity, please.  You are no fun anymore.

[Ondřej Čertík]

Hi Jo,

I am sorry to see you leaving. The door is always open if you want to come back.
Thanks for all your contributions.

Ondrej

[Joachim Durchholz]

Am 30.01.2015 um 17:35 schrieb Ondřej Čertík:
> The door is always open if you want to come back.

I'll bring a revolving door :-D

Some aspects I was made aware of in private mails have made that
quitting decision far less certain than I thought just yesterday.
So... I'm reconsidering, and testing approaches, and seeing how it all
works out.

Thanks for all the feedback: the praise and the criticism, it has both
been very valuable for me.

Regards,
Jo

[Sergey Kirpichev]

On Sunday, February 1, 2015 at 1:19:35 AM UTC+3, Joachim Durchholz wrote:

Am 30.01.2015 um 17:35 schrieb Ondřej Čertík:
> The door is always open if you want to come back.

I'll bring a revolving door :-D

Some aspects I was made aware of in private mails have made that
quitting decision far less certain than I thought just yesterday.

Oh, SymPy is safe now! :)

[Roberto Colistete Jr.]

    Sergey, try to make constructive comments, please. Or else don't make comments at all.

    Joachim message was not sent to you, and it seems you want to make the current issue worse.