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
Bug#913659: Document that not all bugs are policy violations
Hello Ian, On Tue 13 Nov 2018 at 05:51PM GMT, Ian Jackson wrote: > The discussion in #913572 is just another instance of the following > antipattern: > >Submitter: program X does strange thing Y which is undesirable >Maintainer: Y is not against policy > > I suggest adding something like this to s1.1, "Scope", as a new 3rd > paragraph: > > This manual cannot and does not prohibit every possible bug or > undesirable behaviour. The fact that something is not forbidden by > Debian policy does not mean that it is not a bug, let alone that it > is desirable. Questions not covered by policy should be evaluated > on their merits. Good idea. This seems strictly informative rather than normative, but I'd like to see some reviews/seconds so that we can confirm that this is how the wider project understands the role of the Policy Manual. (If no seconds but also no objections are forthcoming, I'll just apply it as an informative change.) -- Sean Whitton signature.asc Description: PGP signature
Bug#913659: Document that not all bugs are policy violations
Package: debian-policy Version: 4.2.1.4 The discussion in #913572 is just another instance of the following antipattern: Submitter: program X does strange thing Y which is undesirable Maintainer: Y is not against policy I suggest adding something like this to s1.1, "Scope", as a new 3rd paragraph: This manual cannot and does not prohibit every possible bug or undesirable behaviour. The fact that something is not forbidden by Debian policy does not mean that it is not a bug, let alone that it is desirable. Questions not covered by policy should be evaluated on their merits. 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?
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
Bug#845715: Required targets must not write outside of the source package tree
Stuart Prescott writes ("Bug#845715: Required targets must not write outside of
the source package tree"):
> Bill Allombert wrote:
> > +This restriction is intended to prevent source package builds creating
> > +and depending on state outside of themselves, thus affecting multiple
> > +independent rebuilds. In particular, the required targets must not
> > +attempt to write into ``HOME``.
>
> At the risk of letting perfect be the enemy of good, is it obvious following
> this final remark about HOME that:
Thanks for your attention to detail :-), but:
Yes, I think it is. "In particular" introduces a statement which is
clarifies the meaning of the general rule, and assists the reader, by
giving an example. I don't think "in particular" can be correctly
used to extend (or except from) a general rule in the way required by
the misreadings you are concerned about.
"All felines have four legs. In particular, cats do."
* "All felines have four legs. In particular, dogs do." <- wrong
> It's reasonably common to redefine HOME within d/rules to make the
> build robust against a user's config files and/or to prevent
> unwanted config files being created.
Having said all that, I don't know if it would be worth explicitly
mentioning this very general and useful technique for the benefit of
readers who haven't osmosed or reinvented it.
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.
Bug#690750: Bug#912724: Broken links in developers-reference as published on the Debian's website
Hi, Am Montag, 12. November 2018 schrieb Lev Lamberov: > Вс 04 ноя 2018 @ 12:00 Holger Wansing : > > > Proposal: maybe the easiest way to make all variants (view via debian.org > > and opened locally) work correctly, would be to change it this way: > > > > "This page is also available in > > https://www.debian.org/doc/devel-manuals#devref;>French, > > German, > > Italian, Russian, and Japanese." > > > > since the links on that page are fine and can be linked from everywhere > > with one single static link. > > Of course, there are still some corner cases which do not work (for > > example, > > when you have the packages installed locally, you cannot switch from the > > local english to the local german version via that links, and when you > > have no internet connection, you also get an irritating situation), but > > most > > usecases should be fine, and it would be an improvement compared to the > > current situation, where all links do not work! > > > > Would fix #690750 and #912724. > > > > Comments? > > In case one take a look into other documentation (togather with its > translation), one will not find any such notes and links to > translations. Maybe there's no need in such note in "Debian Developer's > Reference"? Or at least no need in explicit links? What about to remove > it completely or change text to something like "This documentation is > also available in some other languages"? Yes, I had also thought about that. Another benefit would be, that we don't need to rephrase the sentence, when new translations are added or outdated onces removed. But I still would like to make that a link, for usability. Holger -- Sent from my Jolla phone http://www.jolla.com/
