Bug#909550: possible conflict over the /usr/bin/ia namespace
On 15/12/2018 08:41, Chris Lamb wrote: > [Adding ftpmas...@debian.org to CC] > > Hi Antoine et al., > >> So anyways - irl will upload a new package now, presumably -2 or more, >> so i think << 0.242+git20151019-2~ is fine. > > I just went to process this package in NEW but this new upload does > not appear to have happened yet. Is that correct? > https://packages.qa.debian.org/p/python-duckduckgo2/news/20180925T145048Z.html Thanks, Iain. signature.asc Description: OpenPGP digital signature
Bug#909550: possible conflict over the /usr/bin/ia namespace
On 2018-12-15 22:25:58, Chris Lamb wrote: > Antoine Beaupré wrote: > >> >From what I can tell, both were: >> >> https://tracker.debian.org/news/989684/accepted-python-duckduckgo2-0242git20151019-2-source-amd64-into-unstable/ > > Neat, thanks. I've just processed python-internetarchive 1.8.1-1 in > NEW. Thanks!! -- Un éducateur dans l'âme ne prend rien au sérieux que par rapport à ses disciples -- soi-même non excepté. - Nietzsche, "Par delà le bien et le mal"
Bug#909550: possible conflict over the /usr/bin/ia namespace
Antoine Beaupré wrote: > >From what I can tell, both were: > > https://tracker.debian.org/news/989684/accepted-python-duckduckgo2-0242git20151019-2-source-amd64-into-unstable/ Neat, thanks. I've just processed python-internetarchive 1.8.1-1 in NEW. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#909550: possible conflict over the /usr/bin/ia namespace
On 2018-12-15 09:41:50, Chris Lamb wrote: > [Adding ftpmas...@debian.org to CC] > > Hi Antoine et al., > >> So anyways - irl will upload a new package now, presumably -2 or more, >> so i think << 0.242+git20151019-2~ is fine. > > I just went to process this package in NEW but this new upload does > not appear to have happened yet. Is that correct? You mean the NEW upload or the duckduckgo one? >From what I can tell, both were: https://tracker.debian.org/news/989684/accepted-python-duckduckgo2-0242git20151019-2-source-amd64-into-unstable/ https://ftp-master.debian.org/new/python-internetarchive_1.8.1-1.html Did I miss something? Thanks for looking into this! A. -- Gods don't like people not doing much work. People who aren't busy all the time might start to think. - Terry Pratchett, Small Gods
Bug#909550: possible conflict over the /usr/bin/ia namespace
[Adding ftpmas...@debian.org to CC] Hi Antoine et al., > So anyways - irl will upload a new package now, presumably -2 or more, > so i think << 0.242+git20151019-2~ is fine. I just went to process this package in NEW but this new upload does not appear to have happened yet. Is that correct? Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#909550: possible conflict over the /usr/bin/ia namespace
On 2018-09-25 14:33:44, Ian Jackson wrote:
> Antoine Beaupré writes ("Re: possible conflict over the /usr/bin/ia
> namespace"):
>> On 2018-09-25 14:22:44, Ian Jackson wrote:
>> > If you can't get a better idea I would suggest
>> > << 0.242+git20151019-1.1~
>> > which is all versions until the next draft(~)-of-an-nmu (.1).
>>
>> But wouldn't <= 0.242+git20151019-1~ be as effective? Why does it need
>> to be <
> 0.242+git20151019-1 is not <= 0.242+git20151019-1~ so that is
> definitely wrong. Maybe you meant <= 0.242+git20151019-1.1~ ?
> But if I were preparing an NMU I would be intending to use
> 0.242+git20151019-1.1 as the nmu version; and my draft packages would
> be called precisely 0.242+git20151019-1.1~ and don't want to be
> conflicted against. Hence 0.242+git20151019-1.1~
>
> This seems like arcane lore really. Surely this stuff ought to be
> documented somewhere ?
It's super weird corner cases - those are hard to document... I looked
into those places in the policy, for example, and couldn't quite figure
it out:
https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts
https://www.debian.org/doc/debian-policy/ch-relationships.html#syntax-of-relationship-fields
The former does not mention any way to specify the actual version; it
probably should. The latter mentions the comparison operators but it
doesn't go into details into how to use them.
The developer's reference also does not seem to have anything about this
that I could find quickly.
So anyways - irl will upload a new package now, presumably -2 or more,
so i think << 0.242+git20151019-2~ is fine.
A.
--
One of the things the Web teaches us is that everything is connected
(hyperlinks) and we all should work together (standards). Too often
school teaches us that everything is separate (many different
'subjects') and that we should all work alone. - Aaron Swartz
Bug#909550: possible conflict over the /usr/bin/ia namespace
On 2018-09-25 14:25:25, Ian Jackson wrote:
> Iain Learmonth writes ("Re: possible conflict over the /usr/bin/ia
> namespace"):
>> On 25/09/18 14:16, Antoine Beaupré wrote:
>> > ... but it hasn't been migrated to Salsa. Would you be okay to move this
>> > in the Python module's team umbrella (as opposed to simply collab-maint)?
>>
>> The whole salsa thing is not something that I've been able to keep up
>> with. I have git repos locally and I've been moving things to salsa as
>> and when I do updates. You probably shouldn't trust what is on salsa
>> anyway unless we all start using signed commits and tags. The archive is
>> the only true record of packages.
I agree with that, for the record. Like any upload I sponsor or work on,
I review the diff before signing anyways, regardless of the source.
> For packages maintained by very small (or unitary) teams with limited
> collaboration, ad-hoc sharing via personal git repos works OK. And of
> course you can share your git branch more formally with everyone,
> in step with the archive, and with reasonable security, by using `dgit
> push'.
I really should give dgit a try again, but I guess it's a great use case
for people allergic to salsa (pun intended) and that just need a git
repo, right? :)
>> I once looked at doing team maintenance on these packages but there was
>> enough extra policy regarding that team management that I did not have
>> the time to look at it. If you would like to adopt the package and move
>> it into the team then that's fine with me. I am also on the list of "low
>> nmu" maintainers. I am not interested in maintaining the package within
>> the team myself though.
>From what I understand, the Python folks are easy: it's just a way to
get the package some visibility and help, and the overhead is
minimal. You don't have to join the team to upload.
But "collab-maint" (also known as "debian" now on Salsa) also works
fine. I don't need a new package to maintain so I'd be happy to let you
proceed with the future of this one. :)
>> Ok, I will close that in approx 15 minutes. (:
Awesome! I'll proceed with the upload of "internetarchive" (binary and
source, after consulting with #debian-python people) shortly as well.
A.
--
Toute mère doit être mère par choix.
Tout enfant doit être un enfant désiré.
- Henry Morgentaler
Bug#909550: possible conflict over the /usr/bin/ia namespace
Ian Jackson writes ("Re: possible conflict over the /usr/bin/ia namespace"):
> Antoine Beaupré writes ("Re: possible conflict over the /usr/bin/ia
> namespace"):
> > On 2018-09-25 14:22:44, Ian Jackson wrote:
> > > If you can't get a better idea I would suggest
> > > << 0.242+git20151019-1.1~
> > > which is all versions until the next draft(~)-of-an-nmu (.1).
> >
> > But wouldn't <= 0.242+git20151019-1~ be as effective? Why does it need
> > to be <
> 0.242+git20151019-1 is not <= 0.242+git20151019-1~ so that is
> definitely wrong. Maybe you meant <= 0.242+git20151019-1.1~ ?
> But if I were preparing an NMU I would be intending to use
> 0.242+git20151019-1.1 as the nmu version; and my draft packages would
> be called precisely 0.242+git20151019-1.1~ and don't want to be
> conflicted against. Hence 0.242+git20151019-1.1~
I mean, hence << 0.242+git20151019-1.1~
Ian.
Bug#909550: possible conflict over the /usr/bin/ia namespace
Antoine Beaupré writes ("Re: possible conflict over the /usr/bin/ia namespace"):
> On 2018-09-25 14:22:44, Ian Jackson wrote:
> > If you can't get a better idea I would suggest
> > << 0.242+git20151019-1.1~
> > which is all versions until the next draft(~)-of-an-nmu (.1).
>
> But wouldn't <= 0.242+git20151019-1~ be as effective? Why does it need
> to be < These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#909550: possible conflict over the /usr/bin/ia namespace
On 2018-09-25 14:22:44, Ian Jackson wrote:
> Antoine Beaupré writes ("Re: possible conflict over the /usr/bin/ia
> namespace"):
>> Makes sense. How about:
>>
>> Conflicts: python-duckduckgo2 (<= 0.242+git20151019-1)
>>
>> This way we assume any newer upload of the package will remove ia?
>
> That's not a good choice because it excludes (local) backports,
> security updates, etc., which tend to add +something to versions.
> If you can't get a better idea I would suggest
> << 0.242+git20151019-1.1~
> which is all versions until the next draft(~)-of-an-nmu (.1).
But wouldn't <= 0.242+git20151019-1~ be as effective? Why does it need
to be <
Bug#909550: possible conflict over the /usr/bin/ia namespace
Iain Learmonth writes ("Re: possible conflict over the /usr/bin/ia namespace"):
> On 25/09/18 14:16, Antoine Beaupré wrote:
> > ... but it hasn't been migrated to Salsa. Would you be okay to move this
> > in the Python module's team umbrella (as opposed to simply collab-maint)?
>
> The whole salsa thing is not something that I've been able to keep up
> with. I have git repos locally and I've been moving things to salsa as
> and when I do updates. You probably shouldn't trust what is on salsa
> anyway unless we all start using signed commits and tags. The archive is
> the only true record of packages.
For packages maintained by very small (or unitary) teams with limited
collaboration, ad-hoc sharing via personal git repos works OK. And of
course you can share your git branch more formally with everyone,
in step with the archive, and with reasonable security, by using `dgit
push'.
> Ok, I will close that in approx 15 minutes. (:
Yay :-). Please use dgit push, so that you share your
actually-uploaded git branch as well as just the package.
Thanks,
Ian.
(back onto the dgit plug hobby-horse)
Bug#909550: possible conflict over the /usr/bin/ia namespace
On Tue, Sep 25, 2018 at 09:16:44AM -0400, Antoine Beaupré wrote: > On 2018-09-25 13:43:42, Ian Jackson wrote: > > You need to coordinate the transition for the /usr/bin/ia filename. I > > think that means your new internet-archive package should probably > > Conflict: python-duckduckgo2 (<< version-without-ia~) > > > > That can probably be uploaded before the new python-duckduckgo2 but > > the relevant version number should be agreed. > > Makes sense. How about: > > Conflicts: python-duckduckgo2 (<= 0.242+git20151019-1) > > This way we assume any newer upload of the package will remove ia? That'd put a requirement on security updates -- and a program that talks to untrusted remote servers is at risk of requiring such an update. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ 10 people enter a bar: ⣾⠁⢰⠒⠀⣿⡁ • 1 who understands binary, ⢿⡄⠘⠷⠚⠋⠀ • 1 who doesn't, ⠈⠳⣄ • and E who prefer to write it as hex.
Bug#909550: possible conflict over the /usr/bin/ia namespace
Hi, On 25/09/18 14:16, Antoine Beaupré wrote: > Conflicts: python-duckduckgo2 (<= 0.242+git20151019-1) The upload I am currently preparing is 0.242+git20151019-2 > I'd be happy to do that upload, actually. I see the git repo used to be > on Alioth: > > https://alioth-archive.debian.org/git/collab-maint/python-duckduckgo2.git.tar.xz > > ... but it hasn't been migrated to Salsa. Would you be okay to move this > in the Python module's team umbrella (as opposed to simply collab-maint)? The whole salsa thing is not something that I've been able to keep up with. I have git repos locally and I've been moving things to salsa as and when I do updates. You probably shouldn't trust what is on salsa anyway unless we all start using signed commits and tags. The archive is the only true record of packages. I once looked at doing team maintenance on these packages but there was enough extra policy regarding that team management that I did not have the time to look at it. If you would like to adopt the package and move it into the team then that's fine with me. I am also on the list of "low nmu" maintainers. I am not interested in maintaining the package within the team myself though. >> And if you do upload internet-archive before python-duckduckgo2 is >> changed there there should probably be a bug against >> python-duckduckgo2. > > Sure, I'll file that anyways now. Ok, I will close that in approx 15 minutes. (: Thanks, Iain. signature.asc Description: OpenPGP digital signature
Bug#909550: possible conflict over the /usr/bin/ia namespace
Antoine Beaupré writes ("Re: possible conflict over the /usr/bin/ia namespace"):
> Makes sense. How about:
>
> Conflicts: python-duckduckgo2 (<= 0.242+git20151019-1)
>
> This way we assume any newer upload of the package will remove ia?
That's not a good choice because it excludes (local) backports,
security updates, etc., which tend to add +something to versions.
If you can't get a better idea I would suggest
<< 0.242+git20151019-1.1~
which is all versions until the next draft(~)-of-an-nmu (.1).
Ian.
Bug#909550: possible conflict over the /usr/bin/ia namespace
On 2018-09-25 13:43:42, Ian Jackson wrote:
> Antoine Beaupré writes ("Re: possible conflict over the /usr/bin/ia
> namespace"):
>> Great! I would be happy to help with that if you need any assistance.
>> In the meantime, should I just upload IA to NEW? :)
>
> You need to coordinate the transition for the /usr/bin/ia filename. I
> think that means your new internet-archive package should probably
> Conflict: python-duckduckgo2 (<< version-without-ia~)
>
> That can probably be uploaded before the new python-duckduckgo2 but
> the relevant version number should be agreed.
Makes sense. How about:
Conflicts: python-duckduckgo2 (<= 0.242+git20151019-1)
This way we assume any newer upload of the package will remove ia?
I'd be happy to do that upload, actually. I see the git repo used to be
on Alioth:
https://alioth-archive.debian.org/git/collab-maint/python-duckduckgo2.git.tar.xz
... but it hasn't been migrated to Salsa. Would you be okay to move this
in the Python module's team umbrella (as opposed to simply collab-maint)?
> And if you do upload internet-archive before python-duckduckgo2 is
> changed there there should probably be a bug against
> python-duckduckgo2.
Sure, I'll file that anyways now.
> I guess that bug doesn't need to be rc ?
Yeah, that's not RC material, as long as the bug is not forgotten in the
next upload of course. :)
A.
--
Instead of worrying about what somebody else is going to do, which is
not under your control, the important thing is, what are you going to
decide about what is under your control?
- Richard Stallman
Bug#909550: possible conflict over the /usr/bin/ia namespace
Antoine Beaupré writes ("Re: possible conflict over the /usr/bin/ia namespace"):
> Great! I would be happy to help with that if you need any assistance.
> In the meantime, should I just upload IA to NEW? :)
You need to coordinate the transition for the /usr/bin/ia filename. I
think that means your new internet-archive package should probably
Conflict: python-duckduckgo2 (<< version-without-ia~)
That can probably be uploaded before the new python-duckduckgo2 but
the relevant version number should be agreed. And if you do upload
internet-archive before python-duckduckgo2 is changed there there
should probably be a bug against python-duckduckgo2. I guess that bug
doesn't need to be rc ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#909550: possible conflict over the /usr/bin/ia namespace
On 2018-09-25 10:45:07, Iain Learmonth wrote: > Hi, > > On 25/09/18 05:35, Antoine Beaupré wrote: >> I tried to figure out what the other package does: > > It uses the DuckDuckGo instant answers API to give an instant answer on > the command line as a more human friendly version of the ddg command > which is machine-readable but contains more information. > > popcon reports 7 old and 0 recent. > > The ia script was added in a patch and never actually present upstream: > > https://sources.debian.org/src/python-duckduckgo2/0.242+git20151019-1/debian/patches/0001-add-ia-script.patch/ > > I was using this as part of an IRC bot but I now just call Python directly. > > The easiest solution here is probably that I drop that script. It was > never accepted upstream anyway, nor have there been any updates upstream > since 2015. Great! I would be happy to help with that if you need any assistance. In the meantime, should I just upload IA to NEW? :) A. -- To punish me for my contempt for authority, fate made me an authority myself. - Albert Einstein
Bug#909550: possible conflict over the /usr/bin/ia namespace
Hi, On 25/09/18 05:35, Antoine Beaupré wrote: > I tried to figure out what the other package does: It uses the DuckDuckGo instant answers API to give an instant answer on the command line as a more human friendly version of the ddg command which is machine-readable but contains more information. popcon reports 7 old and 0 recent. The ia script was added in a patch and never actually present upstream: https://sources.debian.org/src/python-duckduckgo2/0.242+git20151019-1/debian/patches/0001-add-ia-script.patch/ I was using this as part of an IRC bot but I now just call Python directly. The easiest solution here is probably that I drop that script. It was never accepted upstream anyway, nor have there been any updates upstream since 2015. Thanks, Iain. signature.asc Description: OpenPGP digital signature
Bug#909550: possible conflict over the /usr/bin/ia namespace
Hi, TL;DR: new package from archive.org conflicts with existing `ia` binary from python-duckduckgo2. Policy §10.1 consensus sought. I'm in the process of packaging the Internet Archive (archive.org) Python commandline client and that installs a client that is conveniently called "ia" in /usr/bin. It's a simple wrapper around a more elaborate Python library, but it allows a fairly complete set of operations of the archive like searching, downloading, uploading and deleting data. Unfortunately, apt-file (is there a better way?) tells me that python-duckduckgo2 already claimed that command namespace, along with the ddg command, naturally. I tried to figure out what the other package does: there's no documentation in the Debian package, and neither command supports has inline help or manpages. From what I can tell, the `ddg` command output structured data from a DDG (DuckDuckGo.com) search and `ia` command does a "feel lucky" type of request to output only one answer. This seems to be somewhat related "Instant Answers" API (hence the `ia` acronym) as defined here: https://duckduckgo.com/api So the situation falls directly under section 10.1 of the Policy: https://www.debian.org/doc/debian-policy/ch-files.html#s-binaries > Two different packages must not install programs with different > functionality but with the same filenames. The solution proposed by the policy is to rename one or both of the packages, after a discussion here: > [...] try to find a consensus about which program will have to be > renamed. If a consensus cannot be reached, both programs must be > renamed. Obviously, DDG has the upper hand right now: it's already passed new and is in the archive. My "internetarchive" package is only at the ITP stage (in CC) but it's fairly complete and would be ready for upload. Right now it Conflicts with the DDG package, but that's not the best solution - I would need to rename the commandline binary to respect policy, if I understand it correctly. But before doing that, I want to give the Internet Archive a chance. As an argument for the archive, I would say its acronym is more commonly known and used than DDG's, which I found out for the first time here and never heard about before. Wikipedia agrees; in this disambiguiation page, DDG is not listed at the time of writing, while the Archive is: https://en.wikipedia.org/wiki/IA The "snap" package `ia` also points to the archive's software: https://snapcraft.io/ia Same for FreeBSD and, as far as I can tell, Arch Linux. I would therefore propose for the python-duckduckgo2 ia binary to be renamed to ddg-ia, as its "ia" use is only secondary in the package's purpose. The alternative course of action would be to rename the ia binary in the internetarchive package to "internetarchive" but that's rather long and unusual: all upstream documentation refers to the `ia` binary and this could confuse our users needlessly, especially since other platforms also use the `ia` acronym to refer to the archive as well. The source of the package is available here: https://salsa.debian.org/python-team/modules/python-internetarchive Progress in the packaging can be followed in the CC'd bug report. With good faith and spirit, sorry for the long email and thanks for any feedback! A, PS: there is, incidentally, also the question of how to name this (source and binary!) package: python3-internetarchive, internetarchive and ia would all be interesting names for various reasons. I would prefer the latter, but it would obviously require the DDG side to rename first to make any sense. The Debian Python policy on this is, as far as I know, rather undecided right now, especially for packages like internetarchive that mix libraries and commandline tools. -- I'm no longer accepting the things I cannot change. I'm changing the things I cannot accept. - Angela Davis
