Rename package to scapy3k

[irl]

As secdev/scapy now has Python 3 support, in order to continue supporting this fork in Debian it would ideally be co-installable. To ensure this is possible the package should be renamed to scapy3k and imports should be for scapy3k instead of scapy to use the fork.

[irl]

I'm patching the current release to rename the package to scapy3k in Debian. Unless this change can be merged here, it won't be possible to make further releases available in Debian as this would be a considerable amount of extra work to manually merge changes in the new file hierarchy.

[phaethon]

Just to minimize any possible misunderstandings, can you send me your current patch?

[irl]

It's a huge patch and I just broke it, but I'll give you the outline:

• setup.py:
  • change packages= with s/scapy/scapy3k/g
  • change SCRIPTS= with s/scapy/scapy3k/g
• rename the scripts in bin/
• move the scapy folder to scapy3k
• in the scapy3k folder
  • you can sort of get away with a recursive sed 's/scapy./scapy3k./' but watch out for a logger, scapy_log that will get caught up in this
• update the documentation to point to from scapy3k.all instead of scapy.all
• rename the man page

[phaethon]

What is the plan on providing information to users? E.g. if somebody was using code from this repository (via debian package), has written some code (with from scapy.all import *), and suddenly installing package with the same name does not work as expected - how does he/she gets to know that python3-scapy3k shall be installed instead to keep it working without other changes (besides importing scapy3k)?

[irl]

When updating in Debian, a NEWS file can be added which will be shown to users on upgrade. Outside of Debian, it would need to be made clean in the changelog for the release. My plan though is that all packages in Debian will be depending on the secdev/scapy repository.

Beside user code that is using scapy3k currently, do you plan for scapy3k to continue on? I do wonder if perhaps the right thing to do is drop scapy3k from Debian now that the secdev repository has python3 support.

Does the API offer any features than cannot easily be merged into secdev's repository? Is there any "killer feature" that would mean new projects might choose scapy3k over secdev's scapy?

[phaethon]

To put it shortly - yes, I do plan to continue with this repository for now, and I believe it will benefit the users to have a package for scapy3k in Debian. Give me a notice if you want more extended version for the reasoning and the plans.

[irl]

It would be good to have a more extended reasoning, as I need to be able to also justify this to others that may ask.

[phaethon]

Can you clarify the reasoning to replace a package, which has been used by people since 2015 and still continues to be maintained, with a package whose RC was released in 2018, without a compatibility testing (or analysis) or migration plan between the packages?

[irl]

Personally I'm very grateful that you worked on the fork as without it, I would not have been able to add packet forging capabilities to my software (PATHspider).

For Debian, my primary concern is that packages that depend on Scapy that are in the Debian archives continue to function. I will complete testing of those packages before making any changes and there will be significant QA work.

Now that the secdev repository has Python 3 support however, I would like to move PATHspider over to that as it has been in Debian since 2003 and has a larger community around it. There are also applications in Debian that are currently depending on a Python 2 build of secdev's repository that may be being blocked from porting to Python 3 due to API differences.

Maintaining forks is inefficient, often creates either filesystem or API namespace conflicts, and, most importantly, increases the difficulty of handling security vulnerabilities in the duplicated code. There is precedent for maintaining forks in Debian, but there needs to be a rationale for doing so that will stand up when questioned.

[phaethon]

I am happy that you know that this repo provides working code ;) and thanks for the good words!
Why such a hurry with the question? My own plans with the project are dependent on the quality of secdev/scapy python3 implementation. But I would judge it in a few months rather than now while it is just RC.

[irl]

I'm basically on the edge of releasing PATHspider 2.0 and I'd like to be able to have the same scapy implementation for the whole release cycle. This is my last blocker.

There is also a lot of momentum in Debian for porting to Python 3 and the transition to the secdev package is blocking that.

https://lists.debian.org/debian-devel-announce/2015/04/msg00005.html

Given external factors though, and seeing that this is more work than I had originally thought, I may skip over this for this release and see if it can be addressed for a minor release in March.

[p-l-]

I will use the opportunity of this issue to mention that, in my opinion, this project should not be named Scapy or Scapy3k at all, since Scapy is another project and using the Scapy name is misleading. Since this is a fork, it should have its own name.

Thanks!

[phaethon]

Dear @p-l- , can you tell how @irl could have found it and used in his project if it was called something totally unrelated + you know very well that secdev/scapy refuses to publish any single link to this + someone (I have my list of candidates) even went so far as to delete the link from Wikipedia together with text correctly explaining actual situation?

[p-l-]

You can mention, of course, that your project is "based on Scapy", a "fork of Scapy", "compatible with Scapy", etc. This should ensure that people can find your project.

But you cannot name it Scapy, since this is not the Scapy project. See naftaliharris/tauthon#47 (previously called "Python 2.8" by the author) for an example of similar issues in the OSS community.

Thanks for your understanding.

[phaethon]

I will make decision on the naming after I see if secdev/scapy actually works (it is now just in RC) in a few months. I have been discussing (in November, 2017) naming with Philippe Biondi and he was fine with calling this scapy3k and having "provides: scapy-python3" in debian package. Which makes a difference from the case you referenced.
As you, @p-l-, have worked against the interest of at least some part of community (searching for scapy compatible library on python3 since 2015) I will choose to ignore your position.

[p-l-]

The decision to rename your package should not be based on the fact that the code provided by the Scapy project works or not, or that it is compatible with Python 3 or not.

You have decided to build your own project based on Scapy, which is great (and is totally OK with Scapy's GPL license), but you should not name your project Scapy, since that's the name of the original project. At the very least as a form of respect for the people who actively maintain the project on which you have based your code.

[phaethon]

@p-l- I respect the original author of the scapy and the community around it. But I don't much care about few people misleading the community about possibility to use scapy with python3 over timeframe of several years.

Show me example of your respect for keeping and growing community of scapy users limited to python3 by going to Wikipedia and adding information to match the facts:

• scapy3k is a fork since 2015 to enable python3 compatibility specifically refused at the time by the active maintainers of the bitbucket/secdev/scapy
• it has been source for python3 scapy packages of several Linux distributions including Debian since then
• multiple features were first done in scapy3k to match the demand from community and then later reimplemented in secdev/scapy (supporting PCAPNG, getting rid of libdnet on multiple platforms, which was otherwise show stopper on Windows, matplotlib for some graphs)
• some features are still not supported by secdev/scapy (e.g. integration with tshark, multiple traceroute with graphs, CAN)
• secdev/scapy knew about, but were hiding information from scapy community about existence of scapy3k and python3 support possibilities, while scapy3k always included reference to the origin of the code and letting people judge themselves what to use.

Is there anything not being truth in the list, @p-l- ? Or you prefer Wikipedia not to show these facts and you are happy to see "somebody" deleting it from Wikipedia not leaving a single link to scapy3k? Or you want us playing cat and mouse adding and deleting the information each other day?

Or may be show respect to community and add a section to your documentation assisting people migrating from scapy3k to secdev/scapy python3 implementation.

[p-l-]

I absolutely don't want to start this kind of personal attacks, and I respect both you and this project. Please rename this project.

[irl]

some features are still not supported by secdev/scapy (e.g. integration with tshark, multiple traceroute with graphs, CAN)

@phaethon Please document these things more prominently so it's clearer how the fork differs. They sound cool.

The decision to rename your package should not be based on the fact that the code provided by the Scapy project works or not, or that it is compatible with Python 3 or not.

Debian will be renaming the package, to either scapy3k or to another name of @phaethon's choice. My preference is that this happens in @phaethon's repository as I'm not keen on maintaining a patch. If maintaining the fork in Debian is too much work for me, I will drop it and either someone else can pick it up or it can be removed.

It is less work for me to rename this package as opposed to renaming secdev/scapy as less things in Debian are using scapy3k. To be clear, if this were reversed, I'd probably be arguing for the opposite.

But you cannot name it Scapy, since this is not the Scapy project.

@p-l-: In fairness to @phaethon, when scapy3k started it was the only scapy with support for Python 3. The name conflict was introduced when secdev/scapy started to catch up. On the 3rd November 2016 I was even told that scapy would never have Python 3 support and a new "scapy3" would be written from scratch, so at that time it looked that there would still not be a name conflict as the rewrite would have a new name but the existing library could have a port using the same namespace to ease porting other libraries to Python 3.

This whole thing has been a bit of a mess, but we can fix it. I believe the next step is renaming this package to scapy3k, or another name, and getting Debian packages updated. I note also that Debian only has 0.21 currently for scapy3k and I'm not too encouraged to spend time updating it without seeing the path for building secdev/scapy for Python 3 in Debian (which needs the renaming).

[p-l-]

@irl this naming problem is not related to the fact that Scapy supports Python 3 or not. Even if it didn't, there would be a problem naming a fork using the original project's name.

[irl]

That's for trademark lawyers to decide. My point was not so much the name of the project, but specifically the names installed in the filesystem (§7.4 Debian Policy Manual) and API compatibility between Python 2 and Python 3.

[p-l-]

I don't want to involve lawyers here, I'd rather have this solved amicably.

[irl]

@phaethon I'm not too concerned about what it is you rename it too, renaming it from one thing to another is going to be the same amount of work as long as you don't rename it using EBCDIC control characters.

[anthraxx]

Back to the actual technical issue here, colliding python module name is really suboptimal so using unique /bin/ and python modules names is really something that should happen soonish. thanks

[phaethon]

@anthraxx collision has been there since 2015.

[anthraxx]

@phaethon yes and it should be resolved. now it because actually tehcnicly conflicting as original scapy is python3 capable. I would like to see a module rneame so it can co-exist. Otherwise i gonna drop scapy3k from the Arch Linux repositories (no blackmailing, i just would like to see that i don't need to do this, thats actually why i'm here to ask for a module rename).

[phaethon]

@anthraxx @irl Renaming python module to scapy3k in the latest commit. Testing ongoing until new package release. Feel free to look at it.

[johnthagen]

@phaethon Will there be an deprecation period where things are exported as both scapy and scapy3k so users/developers are notified? Or will the next release break all programs that use scapy-python3?

I know many people (myself included) aren't good about pinning to specific versions, so the next time it's installed the imports would just fail.

[anthraxx]

@phaethon thanks a lot. the original scapy 2.4.0 was released with python3 support so for Arch i gonna mark scapy3k as conflicting scapy (so both exclusive to each other for now) and happily wait and keep scapy3k in the repos and hope a new version with renamed module name is released soon 🐱

[phaethon]

Sorry for not keeping everyone updated, but things change back and forth quite fast last weeks, so that it is not easy to decide what to write :)
Most likely scenario that the package name will change to a different name, and scapy3k will not be the name that will remain. I have not published new PyPI release with the scapy3k package name and will not do it. Sure, I will post when the final name is decided. Hope to have this finalized in May.

[phaethon]

The new name of the repo, python module, and PyPI package will be kamene. Repo is already renamed, the rest is in progress. Some more info on the Readme, but it is still in progress.

@johnthagen you will need to update when the next release will be out. I can give you a separate notice when it is ready to be installed.