Bug#1071007:

[Nilson Silva]

HI
Hey guys!

I just finished updating Sherlock, fixing the conflicts that led to this bug 
being opened.

> Packager can also  get rid of the only- run-one-test solution for unit
> testing, as there is  built in support for  offline-only unit tests via
> either `tox -e  offline` (preferred for consistency) or `pytest -m "not
> online"` and their respective macros


As for the tests, everything went well.  I customized the construction 
according to Paul's instructions.
I will be uploading the new version to Debian, thus closing the Bug.
If new situations arise, feel free to open other notifications.


Thank you all for your help!
Nilson F. Silva

Bug#1071007: Update available upstream

[Paul Pfeister]

Hey all

Upstream has been bumped to 0.15.0, and with this, the importable
module has been renamed from `sherlock` to `sherlock_project`.

Repackaging should allow both Serious bugs to be closed.

As indicated in the prior...

With this, upstream has also moved to adopt properly tagged releases,
so long git ref version numbers should no longer be needed. Proper
version numbers such as 0.15.0-1 are now possible.

Packager can also get rid of the only-run-one-test solution for unit
testing, as there is built in support for offline-only unit tests via
either `tox -e offline` (preferred for consistency) or `pytest -m "not
online"` and their respective macros.

Feel free to reach out with any questions or help with implementation.

Bug#1071007: Sherlock bug update

[Paul Pfeister]

We are planning to bump to 0.15.0 to coordinate merges for all our
planned breaking changes at once

With this, the importable module's name will be changed, avoiding
conflict. I've proposed sherlock_project to match pypi and the egg, as
Thomas recommended.

We also plan to adopt proper tagged releases starting with this
version. This means that long date+commitish version tags like
0.14.4+git20240531.e5ad3c4-2 are theoretically no longer necessary for
downstream. Downstream packages should be able to (in theory) peg
themselves to a version tag for stable and add build numbers after for
later mid-lifecycle/unstable updates or patches (i.e. 0.15.0-1,
0.15.0-2).

Will update everyone soon.

Bug#1071007: Bug#1072733:

[Thomas Goirand]

On 6/10/24 23:43, Paul Pfeister wrote:
When building the rpm, I named the (rpm) package sherlock-project to 
have parity with PyPI, due to the same conflicting package. The 
importable module is still simply sherlock, however, which is _less than 
ideal_, and should probably be addressed.


With this discussion now being had on the deb side, I just introduced 
the conversation about renaming last night.


Still up for debate, but assuming we do decide to change it, we'll most 
likely use sherlock_project (again, for parity). I don't like the 
underscore, but it's the least likely to have conflict. I'll let you 
guys know of the decision.


(executable would remain sherlock even if the package name changes)


Hi!

Am I right, reading this, to double-guess you're also upstream author 
for sherlock (the social media package)? If so, why don't you simply 
change your module name to sherlock-project indeed? That would solve the 
conflict. So I'm all for it. Please make it happen.


Also, having module-name == pypi name == egg-name is a good practice.

Cheers,

Thomas Goirand (zigo)

Bug#1071007:

[Paul Pfeister]

When building the rpm, I named the (rpm) package sherlock-project to have
parity with PyPI, due to the same conflicting package. The importable
module is still simply sherlock, however, which is _less than ideal_, and
should probably be addressed.

With this discussion now being had on the deb side, I just introduced the
conversation about renaming last night.

Still up for debate, but assuming we do decide to change it, we'll most
likely use sherlock_project (again, for parity). I don't like the
underscore, but it's the least likely to have conflict. I'll let you guys
know of the decision.

(executable would remain sherlock even if the package name changes)

Bug#1071007: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py

[Samuel Henrique]

Hello Thomas,

On Mon, 10 Jun 2024 at 12:03, Thomas Goirand  wrote:
>
> On 6/9/24 18:47, Samuel Henrique wrote:
> > Zigo,
> >> I just saw that sherlock (the social networks package) moved its python
> >> files to /usr/share, instead of /usr/lib/python3/dist-packages
> >> . This was
> >> the sensible thing to do, as it doesn't really need to expose itself as
> >> Python module.
> >
> > Not really, that was done by accident when Nilson was trying to remove the
> > system-wide init file (#1071007) and was reverted already.
> >
> > Upstream has mentioned (to me) that their intention is to provide a library 
> > for
> > sherlock, as we've had since the package was introduced.
>
> Well, sherlock is an app, and therefore, it's the sensible thing to do
> to push it's Python code in /usr/share. IMO, it shouldn't have been
> reverted.

The move was done as a workaround for another issue (the global __init__ file),
and upstream mentioned they would like to have the module available, so at the
time the revert was the right choice.

Now that we know there's also a clash with the sherlock package, the situation
is different.

> Normally, the one that owns the PyPi name such as:
> https://pypi.org/project/sherlock/
>
> also get to have the python module name. Clearly, sherlock (the social
> media package) didn't do that.

I agree with this.

> Now, if you know upstream, then probably you can convince them to rename
> their lib to something that doesn't clash? And also, maybe, add its
> software on PyPi?

Sherlock is there, but under https://pypi.org/project/sherlock-project.

So it does look like the right thing to do on Debian's side is to either not
let the module be importable or rename it (ideally done by upstream first).

Paul (as upstream), the sherlock module clashes with
https://pypi.org/project/sherlock/, which was published first and ships a
"sherlock" library.

Do you think it would make sense to change the name of the module provided by
your sherlock (just the module, not the executable), or alternatively for us to
not ship an importable library at all?

This is an issue that's going to happen on other distros as well, as far as I
know.

> >> Therefore, this bug can be closed, and there's IMO nothing more to do in
> >> the python-sherlock (the cluster lock package), as the conflict is now
> >> solved.
> >
> > I'll reopen 1072733 since the clash still exists.
>
> :(

We have a path forward now, at least after Paul replies, so it should be all
good (although the bug stays open until solved, right?!).

Cheers,

--
Samuel Henrique 

Bug#1071007: Bug#1072733: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py

[Thomas Goirand]

On 6/9/24 18:47, Samuel Henrique wrote:

Zigo,

I just saw that sherlock (the social networks package) moved its python
files to /usr/share, instead of /usr/lib/python3/dist-packages
. This was
the sensible thing to do, as it doesn't really need to expose itself as
Python module.


Not really, that was done by accident when Nilson was trying to remove the
system-wide init file (#1071007) and was reverted already.

Upstream has mentioned (to me) that their intention is to provide a library for
sherlock, as we've had since the package was introduced.


Well, sherlock is an app, and therefore, it's the sensible thing to do 
to push it's Python code in /usr/share. IMO, it shouldn't have been 
reverted.


Normally, the one that owns the PyPi name such as:
https://pypi.org/project/sherlock/

also get to have the python module name. Clearly, sherlock (the social 
media package) didn't do that.


Now, if you know upstream, then probably you can convince them to rename 
their lib to something that doesn't clash? And also, maybe, add its 
software on PyPi?



Therefore, this bug can be closed, and there's IMO nothing more to do in
the python-sherlock (the cluster lock package), as the conflict is now
solved.


I'll reopen 1072733 since the clash still exists.


:(

Cheers,

Thomas Goirand (zigo)

Bug#1071007: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py

[Samuel Henrique]

Control: reopen 1072733 =

Hello all,

Chris,
> > I see your point now, it seems like it should be just "Conflicts", do you
> > agree? None of those 2 packages can/should be renamed.
>
> Please see https://www.debian.org/doc/debian-policy/ch-files.html#binaries
>
> Conflicts is not appropriate for programs with different
> functionality.

That link is for binaries, whereas we are dealing with conflicting libraries,
the section just below that one does not say anything about libraries with
conflicting names.

It sounds like you're saying this also applies to libraries and that one of
them needs to be renamed or be dropped. Can you please be specific in what you
think it should happen (if not that)?

Zigo,
> I just saw that sherlock (the social networks package) moved its python
> files to /usr/share, instead of /usr/lib/python3/dist-packages
> . This was
> the sensible thing to do, as it doesn't really need to expose itself as
> Python module.

Not really, that was done by accident when Nilson was trying to remove the
system-wide init file (#1071007) and was reverted already.

Upstream has mentioned (to me) that their intention is to provide a library for
sherlock, as we've had since the package was introduced.

> Therefore, this bug can be closed, and there's IMO nothing more to do in
> the python-sherlock (the cluster lock package), as the conflict is now
> solved.

I'll reopen 1072733 since the clash still exists.


Cheers,


--
Samuel Henrique 

Bug#1071007: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py

[Chris Hofstaedtler]

* Samuel Henrique  [240608 20:37]:
> > If they share a name but none of the API / features, then it is not
> > a correct solution.
> 
> They do not share the same API.
> 
> > These descriptions do not sound related at all. In this case,
> > Conflicts/Replaces is not appropriate.
> 
> I see your point now, it seems like it should be just "Conflicts", do you
> agree? None of those 2 packages can/should be renamed.

Please see https://www.debian.org/doc/debian-policy/ch-files.html#binaries

Conflicts is not appropriate for programs with different
functionality.

Chris

Bug#1071007:

[Paul Pfeister]

Hey all

Thanks for your patience. Life gets a bit busy sometimes.

I've just merged #2127 [1] upstream, switching Sherlock from
setup-tools to Poetry, from unittest to pytest, and adding tox. With
this, the site-/dist-packages dir is no longer dirtied. This bug
**should** be resolved with the new upstream.

All:
Please feel free to ping me somewhere if things are problematic. I
don't get emails for this thread despite subscribing for some reason,
so I just check in once in a while. Things seem to work well on our
end though, and I don't suspect any major issues

For the packager:
Not terribly sure if Debian builds need to occur offline, but if they do...
If using tox... `tox -e offline` will direct tox to ignore
internet-dependant unit tests
If using pytest directly... `pytest -v -m "not online"` will direct
pytest to do the same

[1]: https://github.com/sherlock-project/sherlock/pull/2127

Bug#1071007: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py

[Samuel Henrique]

Hello Chris,

> > > Per Debian policy this is not the correct solution for naming conflicts. 
> > > Both
> > > maintainer (teams), please find a policy compliant solution together.
> >
> > The solution for this one seems correct, it's a Conflict + Replaces because
> > both packages provide a "sherlock" library. Am I missing something?
>
> Do both packages provide the same API? IOW: do they provide the same
> "type" of library?
> If so, then Conficts/Replaces may be appropriate.
>
> If they share a name but none of the API / features, then it is not
> a correct solution.

They do not share the same API.

> These descriptions do not sound related at all. In this case,
> Conflicts/Replaces is not appropriate.

I see your point now, it seems like it should be just "Conflicts", do you
agree? None of those 2 packages can/should be renamed.

Cheers,

--
Samuel Henrique 

Bug#1071007: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py

[Chris Hofstaedtler]

Hi Samuel,

only replying to your question below, with new questions.

* Samuel Henrique  [240608 14:04]:
> For #1072733:
> 
> Chris
> > Per Debian policy this is not the correct solution for naming conflicts. 
> > Both
> > maintainer (teams), please find a policy compliant solution together.
> 
> The solution for this one seems correct, it's a Conflict + Replaces because
> both packages provide a "sherlock" library. Am I missing something?

Do both packages provide the same API? IOW: do they provide the same
"type" of library?
If so, then Conficts/Replaces may be appropriate.

If they share a name but none of the API / features, then it is not
a correct solution. 

Looking at the package descriptions on tracker.d.o:

python-sherlock:
  distributed inter-process locks with a choice of backend

sherlock:
  Find usernames across social networks

These descriptions do not sound related at all. In this case,
Conflicts/Replaces is not appropriate.

Chris

Bug#1071007:

[Nilson Silva]

Hi everybody!

Firstly, we have to make it clear that we have two distinct bugs:

They seem to be the same because you are bumping into the only files they have 
in common:
__init__.py


The first bug was due to Sherlock installing his modules in the root of the 
package directories.
 This has so far been resolved by the patch. I sent it upstream, in case he 
wanted to merge until he
 changed to another beckand(poetry), however I left him free to accept it or 
not. And I made clear the reasons why I sent it.
https://github.com/sherlock-project/sherlock/pull/2147

The other problem is because there is the same project with the same name as 
sherlock, although its
name is python-sherlock, upstream in its code calls it "sherlock".

The question is to solve the problem, one of the projects will have to change 
the name
of both pyproject.toml and also change the name of its main module and create 
nicknames
for its "imports". In my opinion, several files will have to be patched

Or as an alternative
We could make Sherlock install its modules in the package root again. 

The question is when Sherlock joins Poetry, we will have the problem again, 
as there would once again be a directory called Sherlock.

Nilson F. Silva

Bug#1071007: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py

[Samuel Henrique]

Control: tags 1072733 moreinfo
Control: reopen 1071007 =

Hello all,

I wasn't subscribed to both bugs so I missed some of the replies, I'm
subscribed now.

I'm sending this reply to both #1072733 and #1071007 because they are related
and I'm trying to clarify the situation on both.

Summary:
#1072733 is a bug caused by a tentative fix of #1071007, I believe Francisco
made the right approach there, but maybe I'm missing something, Chris?

#1071007 is still not fully fixed as the approach is problematic.

We should not submit workarounds to upstream when they already pointed out a PR
which should address the issue.

If we need to perform a workaround on our side in the meantime, we need to make
sure it works and we should not submit it upstream (they already have the
proper fix in progress).

Plan:
Let's try to fix this issue using upstream's PR.

If we spot issues with the PR, we can contribute back (but let's make sure it
makes sense to upstream).

If we end up performing a workaround, let's make sure it works and doesn't
cause other issues. It's ok to let the package be removed from testing until
this gets fixed.

If we really want to avoid the package being removed from testing, we can
package a previous release where the issue wasn't present (using the "+really"
versioning mechanism).

The end goal is to get this fixed before the freeze, so we have time.

Now the lengthy replies below:

For #1072733:

Chris
> Per Debian policy this is not the correct solution for naming conflicts. Both
> maintainer (teams), please find a policy compliant solution together.

The solution for this one seems correct, it's a Conflict + Replaces because
both packages provide a "sherlock" library. Am I missing something?

Note that this bug is different from #1071007, they look very similar and
initially I thought they were a dupe.

Nilson
> Your package should not be called in d/rules:
> export PYBUILD_NAME=python-sherlock
> or something similar that wasn't exactly sherlock?

We should keep the same name as changing it will cause issues for users, this
is a real case of a conflicting library name.

For #1071007:

Nilson,
> I just pushed a new version of shelock with a fix for the problem in the
> "master" branch. If that's ok, I'll do a merge.
> https://salsa.debian.org/pkg-security-team/sherlock/-/tree/master?ref_type=heads

We follow the DEP14 for git branching, that means we do namespacing. When
dealing with temp/wip branches, the recommendation is to push to
$username/$branchname. If you push to master, it will lead to confusion as to
which branch is the main one (it's debian/master).

It looks like that branch has been merged into debian/master but master has not
been deleted yet. We have to remove that branch.

> This led to the bug being reopened twice as RC, leading to its removal from
> "testing" even after > pycrc had resolved its conflict issue.

We always try to avoid getting a package removed from testing, but sometimes it
happens and that's ok, once the issue is fixed the package will get back. This
is only worrying when removing the package causes a cascade effect or when we
are close to the freeze for stable.

We don't have to rush for a fix in this case, it's better to be precise.

> I made a pull request to usptream
> https://github.com/sherlock-project/sherlock/pull/2147

We should not be submitting this to upstream when they already pointed us to a
PR that solves the issue. We have to try working with that PR. If  that's not
possible, we can patch it ourselves with a different approach, but we should
not submit our workaround to upstream because they already have a proper
solution in progress.

> In accordance with the other Package Uploaders,
> Debian Developer, Francisco Vilmar.
> I will be closing the bug.
> Since the problem itself, with Sherlock installing its
modules in the root of the packages, has been fixed.

The upload done by Francisco for #1072733 can't be used to close #1071007, he
was fixing an issue caused by one of the uploads that tried to fix #1071007, it
was not fixing #1071007 itself.

> sherlock (0.14.4+git20240531.e5ad3c4-1) unstable; urgency=medium
> .
>   * New upstream version 0.14.4+git20240531.e5ad3c4
>   * debian/patches: Adjusted directory installation package (Closes: #1071007)

This upload is indeed trying to solve #1071007 by patching the source code
instead of pulling the upstream PR.
Looking at the list of files shiped [0], the egginfo files are in the wrong
place.

I also find the following commit confusing:
https://salsa.debian.org/pkg-security-team/sherlock/-/commit/fc6e9929b1018d411df599a68d5898e42bfe6560

The commit description does not mention what/why the changes are being made,
for example, why the change from dh_auto_install to dh_install.

Cheers,

[0] https://packages.debian.org/trixie/all/sherlock/filelist

--
Samuel Henrique 

Bug#1071007:

[Nilson Silva]

In accordance with the other Package Uploaders,
Debian Developer, Francisco Vilmar.
I will be closing the bug.

Since the problem itself, with Sherlock installing its
modules in the root of the packages, has been fixed.



Nilson F. Silva

Bug#1071007:

[Nilson Silva]

Hi Paul!

Just clarifying!

My goal with this patch was to just solve a conflict problem by trying, not 
changing your code through a patch.

But unfortunately, both attempts were not accepted by Samuel, as they did not 
solve the problem itself.

This led to the bug being reopened twice as RC, leading to its removal from 
"testing" even after pycrc had resolved its conflict issue.

I wouldn't want the removal to happen.


Another thing:
This PR =>
https://github.com/sherlock-project/sherlock/pull/2127

It involves significant changes, both in terms of packaging (poetry) and the 
implementation of unit tests and even with tox.

I would need to see how these changes would affect packaging in the Debian 
environment.

If Samuel agrees, I will upload this patch. And this transition from setuptools 
to poetry would be for later, until we see how Sherlock would behave in Debian.



Nilson F. Silva

Bug#1071007:

[Nilson Silva]

Hi Samuel!
I hope you are well!
I'm sorry for responding so late.
I had a problem with my laptop keyboard.

I just pushed a new version of shelock with a fix for the problem in the 
"master" branch.
If that's ok, I'll do a merge.
https://salsa.debian.org/pkg-security-team/sherlock/-/tree/master?ref_type=heads

Now Sherlock can install his modules in his own directory.

I made a pull request to usptream 
https://github.com/sherlock-project/sherlock/pull/2147

I'll wait for you to review the fix, to avoid this bug being closed and 
reopened again.
[https://salsa.debian.org/assets/twitter_card-570ddb06edf56a2312253c5872489847a0f385112ddbcd71ccfa1570febab5d2.jpg]
Files
 · master · Debian Security Tools Packaging Team / sherlock · 
GitLab
sherlock
 packaging
salsa.debian.org


Nilson F. Silva

Bug#1071007: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py

[Samuel Henrique]

Control: reopen -1 =

> I have read the other replies to the bug, which I missed previously.
> It's not upstream's intention to ship the modules in dist-packages.

Nevermind this, I misread upstream's response. Upstream contacted me to ask
about it and it's clear to me now.

Nilson:
> As Sherlock is a private module, I moved it to usr/share according to this
> policy here:

Sherlock is not a private module.

Please proceed with importing the upstream PR to fix the issue.

Cheers,

--
Samuel Henrique 

Bug#1071007: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py

[Samuel Henrique]

Control: reopen -1 =

The latest upload broke the package, this time by mis-placing the files in
/usr/share/:
https://salsa.debian.org/pkg-security-team/sherlock/-/commit/58dacca3117b66341a4371431d6f38a1d35b08c9
https://salsa.debian.org/pkg-security-team/sherlock/-/commit/00a20c5cc3a9c42a295e886dee1db49472338c4e

The commit "58dacca3117b66341a4371431d6f38a1d35b08c" is also doing more than
what's described in its message. I'm not sure dh_link is the right place to
remove test files, but I haven't looked into that deeply.

This breaks the ability to import sherlock into other python scripts, since
it's not under dist-packages anymore.

The original proposed solution to the issue still stands: we just need to not
ship files at the root of dist-packages.

Regards,

-- 
Samuel Henrique 

Bug#1071007:

[Nilson Silva]

Hi!
As Sherlock is a private module, I moved it to usr/share according to this 
policy here:
https://www.debian.org/doc/packaging-manuals/python-policy/#programs-shipping-private-modules
It is not necessary to __init__py of the package as suggested by Samuel.

Thank you everyone for your help!

Nilson F. Silva

Bug#1071007:

[Paul Pfeister]

All --

::: Re: 1071007, ALL CONCERNED :::

I am associated with the upstream project.
This is a real bug. Discovered it some time last week. This seems to have
been introduced when we added the new pyproject file with a setuptools
backend.

For some unknown reason, the installed package would dump its files into
either the dist-packages/site-packages dir rather than a package-named
subdir, or it would for even more mysterious reasons dump the src files
into _both_ dirs at the same time. This behavior was present no matter the
install method -- whether pip, rpm, etc.

I have resolved this bug in upstream PR #2111 (below), with a switch from
setuptools to Poetry, among several other more minor tasks. This PR is
currently undergoing review, but I expect it to be merged shortly. Once
merged, the packager here can pull and repack (or they can patch to in the
interim).

https://github.com/sherlock-project/sherlock/pull/2111

::: FOR THE PKG MAINTAINER :::

Since Poetry doesn't support dynamic versioning in the same way setuptools
did, that part of the workflow has to change a bit once this PR is merged.

Dynamic versioning now occurs via `poetry build` with the
`poetry-version-plugin` plugin installed alongside. Since many automated
workflows rely on pip, you may need to adapt it slightly. Reference the
spec file here for an example of how I adapted the rpm build workflow for
this. L43 and L44 run a quick sed to fetch and populate the version number
from the __init__ as the single source of truth.

https://github.com/ppfeister/pkg/blob/3959a6ef6c8a2318ae183a8e5d85241eb8f756bf/sherlock/sherlock-project.spec

If you're able to use Poetry with plugins as part of your workflow, then
that change may be moot.

::: ALL /> :::

Feel free to reach out if you have any questions.

Bug#1071007: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py

[Eriberto]

Em sáb., 18 de mai. de 2024 às 21:08, Samuel Henrique
 escreveu:
>
> Control: reopen -1 =
>
> I see on git that the bug was closed with a Conflicts+Replaces stanza, but
> that's not the correct solution for this issue.
>
> As discussed on this bugreport, the fix is to not ship the file.
>
> Reopening to block the problematic package to migrate to testing.
>
> Cheers,
>
> --
> Samuel Henrique 
>

In addition, 'Conflicts' is a very extreme solution for many use cases.

Eriberto

Bug#1071007: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py

[Samuel Henrique]

Control: reopen -1 =

I see on git that the bug was closed with a Conflicts+Replaces stanza, but
that's not the correct solution for this issue.

As discussed on this bugreport, the fix is to not ship the file.

Reopening to block the problematic package to migrate to testing.

Cheers,

--
Samuel Henrique 

Bug#1071007: sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py

[Axel Beckert]

Control: affects -1 - pycrc
Control: clone -1 -2 -3
Control: reassign -2 pycrc 0.10.0-2
Control: retitle -1 sherlock: Must not ship 
/usr/lib/python3/dist-packages/__init__.py
Control: retitle -2 pycrc: Must not ship 
/usr/lib/python3/dist-packages/__init__.py
Control: reassign -3 lintian 2.117.0
Control: severity -3 wishlist
Control: retitle -3 lintian: Should warn if a package ships 
/usr/lib/python*/dist-packages/__init__.py

Hi Helmut,

Helmut Grohne wrote:
> This bug report has been automatically filed with no human intervention.
> The source code is available at https://salsa.debian.org/helmutg/dumat.

Ok, this explains why you didn't notice that this is actually a
separate bug in each of these packages. :-)

> sherlock has an undeclared file conflict. This may result in an unpack
> error from dpkg.
> 
> The file /usr/lib/python3/dist-packages/__init__.py is contained in the
> packages
>  * pycrc/0.10.0-2 as present in trixie|unstable
>  * sherlock/0.14.3+git20240511.b83f5be-1 as present in unstable

My Python foo isn't that well versed, but as far as I understand
actually no package must ship an __init__.py file at (more or less)
root level (i.e. directly in /usr/lib/python*/dist-packages/ or — since
usrmerge also — /lib/python*/dist-packages/).

Accordingly cloning the bug report for pycrc as it must not ship that
file either.

And cloning it a second time as wishlist bug report against Lintian so
that these cases get caught much earlier. Might be implemented as
extension of python-module-has-overly-generic-name (as the module name
seems the empty string in that case ;-) which so far already catches
cases like e.g. /usr/lib/python3/dist-packages/doc/__init__.py.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Bug#1071007: sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py

[Helmut Grohne]

Package: sherlock
Version: 0.14.3+git20240511.b83f5be-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + pycrc

sherlock has an undeclared file conflict. This may result in an unpack
error from dpkg.

The file /usr/lib/python3/dist-packages/__init__.py is contained in the
packages
 * pycrc/0.10.0-2 as present in trixie|unstable
 * sherlock/0.14.3+git20240511.b83f5be-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.