Hi Gabriel,
sorry for the late reply. Replying to your original mail as I already
had written half the mail a few days ago.
Gabriel F. T. Gomes wrote:
> >> I cloned the package repository and I understood how syncing with
> >> upstream was designed (very clever, imo).
> >
> >Nice! Didn't look that deep into the package.
>
> At the time I sent my first email, I was unaware of the existence of
> git-buildpackage. It turned out that bash-completion is maintained
> with it, so that's where the clever syncing with upstream comes from.
Ah, ok. :-)
> (As a side not, I'm glad I learned about it, because it helped me in
> the other packaging I am working on (pragha). I converted it to
> git-builbpackage)
Good! :-)
> >Yes, but IMHO it's definitely a good thing to synchronise these bug
> >reports (well, those which are still valid) to Github or the Debian
> >Bug Tracking system — especially since Alioth is going away towards
> >end of this year.
> >[...]
> >Not sure if it might be a good idea to make a dump or copy of all
> >these bug reports as I don't expect them to be preserved when Alioth
> >is decommissioned.
>
> I saved the results of your search filter as a CSV, so that I have more
> time to work on it. Should that be enough?
I hope so. Definitely better than nothing.
> I'm keeping my work on a personal git server [1], but as I mentioned in
> the RFS for pragha [2], I don't think that's a good place to keep these
> files in the long term, because I do not fully trust myself as a
> sysadmin.
Should suffice for the moment. It's probably best to wait until
Debian's Alioth replacement is available.
> After I upgraded bash-completion to newer upstream releases, I got some
> conflicts during the installation of the package. For instance, it
> complained about the existence of the completion file for adb:
>
> dpkg: error processing archive
> /home/gftg/debian/bash-completion/bash-completion_2.7-1_all.deb (--install):
> trying to overwrite '/usr/share/bash-completion/completions/adb', which is
> also in package adb 1:7.0.0+r33-2
>
> I know that bts (from packages devscripts) and mount/umount (from
> package mount) have the same problem, because I locally removed them
> from bash-completion (just to test).
>
> However, I don't know what to do about it. There should be certainly
> more files that collide this way, but I only saw these in my computer,
> because I have few packages installed.
This is a very common issue with bash-completion and zsh-common (where
zsh's default completions live), but it's also unique to those two
packages.
Background: Some projects maintain shell completions rather well,
others don't, but the team maintaining the completions does maintain
them. If new completions are added to bash-completions, it's often a
sign that the project they're for, doesn't really maintain them.
So you should compare the conflicting files: Which are more uptodate,
which have more precise completion.
If it's the one in the project's package, just don't ship the one in
bash-completion and it's good.
If the newly appeared file in bash-completion is clearly the better,
you should maybe not ship it now, but file a bug report against the
other package to exclude it, and if that's done, add in your next
upload Breaks + Replaces headers against the last version of the
package which still contained the conflicting file.
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, 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
