Re: [Pkg-rust-maintainers] Bug#913572: Shouldn't shipping broken symlinks be against policy?
On Wed, Nov 14, 2018 at 07:07:35PM +1100, Angus Lees wrote: > Suggestions welcome - I imagine this is not a unique situation. I think > our options are: > - no rust-gdb manpage at all > - a .so stub or symlink to gdb.1 (current situation) Note that gdb.1 is in non-free and not in the gdb package. > - a manually-created stub manpage that just refers the reader to > gdb-doc/gdb.1 This is probably the best option. This way the user get the memo that rust-gdb is a gdb wrapper with the same option as gdb, and whether they want to install the non-free gdb-doc is up to them. With the current set up, doing 'man rust-gdb' either give you nothing or the gdb manpage which in both case does not tell you what rust-gdb is and why you would want to use it instead of gdb. Cheers, -- Bill. Imagine a large red swirl here.
Re: [Pkg-rust-maintainers] Bug#913572: Shouldn't shipping broken symlinks be against policy?
On 11/14/18 9:07 AM, Angus Lees wrote: > Suggestions welcome - I imagine this is not a unique situation. I think > our options are: > - no rust-gdb manpage at all > - a .so stub or symlink to gdb.1 (current situation) > - a manually-created stub manpage that just refers the reader to > gdb-doc/gdb.1 > - (something else?) > > I suspect you're going to choose that 3rd option, since it is the least > terrible and suggestions are almost free to make :) > I'd say in the absence of a manpage for rust-gdb specifically, option 1 is better than the current setup. IMO typing "man rust-gdb" and ending up with the gdb manpage would be very much unexpected. Cheers, Julien
Re: [Pkg-rust-maintainers] Bug#913572: Shouldn't shipping broken symlinks be against policy?
I think I am responsible for this dangling symlink :) The issue is that the symlink target is _not_ in the 'rust-doc' package, but in the 'gdb-doc' package which has nothing to do with the rust src package, nor the rust maintainers. Moving the rust-gdb symlink into gdb-doc is not appropriate. Background: rust-gdb is a tiny shell wrapper around gdb, that provides some extra command line flags to set things up for debugging a rust program. It doesn't have a manpage upstream. We could write one, but it would look almost exactly like the gdb manpage since - again - just a wrapper. So currently the rust-gdb package ships a rust-gdb.1.gz symlink that points to gdb.1.gz (from the gdb-doc package). Iirc, I originally created it as a ".so" stub troff file pointing to gdb.1, but some tool along the way strongly suggested I replace that with the dangling symlink you see today. Suggestions welcome - I imagine this is not a unique situation. I think our options are: - no rust-gdb manpage at all - a .so stub or symlink to gdb.1 (current situation) - a manually-created stub manpage that just refers the reader to gdb-doc/gdb.1 - (something else?) I suspect you're going to choose that 3rd option, since it is the least terrible and suggestions are almost free to make :) NB: I'm ignoring the implied larger question of whether shipping broken symlinks should or should not be against Debian policy. I'll leave that for the gallery to consider. - Gus
Re: [Pkg-rust-maintainers] Bug#913572: Shouldn't shipping broken symlinks be against policy?
G. Branden Robinson: > [..] > $ man rust-gdb > /usr/bin/man: warning: /usr/share/man/man1/rust-gdb.1.gz is a dangling symlink > No manual entry for rust-gdb > See 'man 7 undocumented' for help when manual pages are not available. > >> The man page is available in the rust-doc package which is already in >> Suggests. > > In that case, isn't a better fix to put the symlink in that package, > too? > Sorry, I made a typo. I meant that the man page (the target of the symlink) is in the gdb-doc package, which is already in the Suggests: of rust-gdb (the offending package containing the potentially-broken symlink). The subsequent side replies to this thread (that I didn't directly respond to) were commenting on an incorrect situation, sorry to have wasted people's time. In order to fix the bug I would have to either a) rust-gdb Depends: gdb-doc, or b) split rust-gdb into rust-gdb vs rust-gdb-doc where the latter Depends: gdb-doc and provides only 1 symlink Both are IMO worse options than leaving the current situation as-is. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Re: Shouldn't shipping broken symlinks be against policy?
G. Branden Robinson writes ("Re: Shouldn't shipping broken symlinks be against
policy?"):
> At 2018-11-13T17:02:49+, Ian Jackson wrote:
> > I guess the maintainer will also think this is a bug.
>
> No; he closed it, and cited Policy's lack of a prohibition of shipping
> broken symlinks in support of the present arrangement.
I was perplexed as to why you didn't give a reference to the bug. But
I am being stupid. The bug is this bug, #913572 !
Anyway, policy doesn't prohibit a program from randomly coredumping
either.
I hope that this discussion will persuade the maintainer to reconsider
their decision. The maintainer says
if it doesn't affect the functionality of the package
but of course this symlink does have a functional effect: it causes
an undesirable warning message from man.
Ximin, is there some reason why you can't move the symlink to the -doc
package along with the manpage it refers to ?
Thanks,
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.
Re: Shouldn't shipping broken symlinks be against policy?
At 2018-11-13T17:02:49+, Ian Jackson wrote:
> G. Branden Robinson writes ("Shouldn't shipping broken symlinks be against
> policy?"):
> > Not reopening, but I have some questions for the Policy team.
> ...
> > I could have sworn you were incorrect, but sure enough, I read §10.5
> > carefully and grepped the rest of the policy manual and could find no
> > such prohibition.
>
> I don't think there is anything *inherently* wrong in shipping a
> broken symlink.
I almost do. :-D
> But if a broken symlink causes some kind of malfunction then that
> seems to be just a bug. Not every bug is a bug because it contravenes
> policy. Some bugs are just bugs :-).
>
> > Well, when a package ships a man page, I expect something more
> > illuminating to happen than:
> >
> > $ man rust-gdb
> > /usr/bin/man: warning: /usr/share/man/man1/rust-gdb.1.gz is a dangling
> > symlink
> > No manual entry for rust-gdb
> > See 'man 7 undocumented' for help when manual pages are not available.
>
> I agree that this is untidy and undesirable. I don't see any good
> reason why one would want to do this rather than shipping the
> rust-gdb.1.gz symlink in the same package as the thing it points to.
>
> I guess the maintainer will also think this is a bug.
No; he closed it, and cited Policy's lack of a prohibition of shipping
broken symlinks in support of the present arrangement.
> Did anyone report it ?
That would be me.
--
Regards,
Branden
signature.asc
Description: PGP signature
Re: Shouldn't shipping broken symlinks be against policy?
G. Branden Robinson writes ("Shouldn't shipping broken symlinks be against
policy?"):
> Not reopening, but I have some questions for the Policy team.
...
> I could have sworn you were incorrect, but sure enough, I read §10.5
> carefully and grepped the rest of the policy manual and could find no
> such prohibition.
I don't think there is anything *inherently* wrong in shipping a
broken symlink.
But if a broken symlink causes some kind of malfunction then that
seems to be just a bug. Not every bug is a bug because it contravenes
policy. Some bugs are just bugs :-).
> Well, when a package ships a man page, I expect something more
> illuminating to happen than:
>
> $ man rust-gdb
> /usr/bin/man: warning: /usr/share/man/man1/rust-gdb.1.gz is a dangling symlink
> No manual entry for rust-gdb
> See 'man 7 undocumented' for help when manual pages are not available.
I agree that this is untidy and undesirable. I don't see any good
reason why one would want to do this rather than shipping the
rust-gdb.1.gz symlink in the same package as the thing it points to.
I guess the maintainer will also think this is a bug. Did anyone
report it ?
Ian.
Shouldn't shipping broken symlinks be against policy?
Not reopening, but I have some questions for the Policy team. At 2018-11-13T16:26:00+, Ximin Luo wrote: > Control: notfound -1 1.28.0+dfsg1-2 > > Closing, as far as I can tell it is not against Policy to ship a > broken symlink, I could have sworn you were incorrect, but sure enough, I read §10.5 carefully and grepped the rest of the policy manual and could find no such prohibition. It is certainly untidy. So I ask the Policy team--_shouldn't_ it be prohibited? > if it doesn't affect the functionality of the package. Well, when a package ships a man page, I expect something more illuminating to happen than: $ man rust-gdb /usr/bin/man: warning: /usr/share/man/man1/rust-gdb.1.gz is a dangling symlink No manual entry for rust-gdb See 'man 7 undocumented' for help when manual pages are not available. > The man page is available in the rust-doc package which is already in > Suggests. In that case, isn't a better fix to put the symlink in that package, too? On my buster system, this is the only one of over 4,300 symlinks in /usr/share/man that is broken: $ find /usr/share/man -type l | wc -l; for F in $(find /usr/share/man \ -type l); do if ! test -f "$F"; then file "$F"; dpkg -S "$F"; fi; done 4938 /usr/share/man/man1/rust-gdb.1.gz: broken symbolic link to gdb.1.gz rust-gdb: /usr/share/man/man1/rust-gdb.1.gz > X > > G. Branden Robinson: > > Package: rust-gdb > > Version: 1.28.0+dfsg1-2 > > Severity: normal > > File: /usr/share/man/man1/rust-gdb.1.gz > > > > $ dpkg -S /usr/share/man/man1/rust-gdb.1.gz > > rust-gdb: /usr/share/man/man1/rust-gdb.1.gz > > > > $ file /usr/share/man/man1/rust-gdb.1.gz > > /usr/share/man/man1/rust-gdb.1.gz: broken symbolic link to gdb.1.gz [snip] Thanks for your time. Policy mavens, please CC me or the bug on replies; I don't subscribe to a billion lists like I did in the old days. Regards, Branden signature.asc Description: PGP signature
