bug maintenance, last comment.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

bug maintenance, last comment.

Nathanael Nerode-5
Scott James Remnant:
>   I don't
> consider old bugs to be worthy of discard,
You mean, "I don't consider unreproducible bugs to be worthy of discard,"
right?  Old reproducible bugs (like 2531, the third oldest open bug in
Debian) are one thing and they should certainly be kept.

Incidentally, could you take a look at 2531 and respond to my comment of 22
September 2005?  My analysis was that it's unreasonable to ask a program
written in perl to use fcntl, and that it's likewise unreasonable to ask for
a complete rewrite of install-info and friends, but that it would make sense
to fix install-info to use flock properly (which it currently doesn't).  Or
do you just keep the old bugs open for entertainment value, without any real
intention of paying attention to them?

Old unreproducible bugs are quite another thing, and I *really* don't see why
you keep them open.

Anyway, the patch tag is objectively false for many dpkg bugs according to the
current definition of the tag ("effective, satisfactory fix supplied"), which
is a good way to mislead Debian users.

> and frankly, it's my bug
> list.
OK.  But don't expect anyone to *ever* volunteer to help with it if you like
to keep it filled with lying tags (like, say, the "unreproducible" tag on
96813, which was added while it was a bug against debconf; or the 'patch' tag
on 35573, which has been 'patched' since 2002 apparently without maintainer
interest).  This is an excellent way both to discourage anyone from trying to
fix bugs in dpkg, and to give the impression that you don't plan to fix them
ever.

Thanks for your maintenance of dpkg.  I realize you've had a lot of bugs to
catch up on since you took over.  :-P


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bug maintenance, last comment.

Joey Hess
Nathanael Nerode wrote:
> My analysis was that it's unreasonable to ask a program
> written in perl to use fcntl

That's weird, there's

a) POSIX::fcntl
b) strace perl -e 'flock(1, "/etc/passwd")' 2>&1 |egrep '^flock|^fcntl'
   fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0

   perl has used fcntl internally for its flock builtin for some time

--
see shy jo

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

OK, that rocks. (was Re: bug maintenance, last comment.

Nathanael Nerode-5
>Nathanael Nerode wrote:
>> My analysis was that it's unreasonable to ask a program
>> written in perl to use fcntl
>
>That's weird, there's
>
>a) POSIX::fcntl
>b) strace perl -e 'flock(1, "/etc/passwd")' 2>&1 |egrep '^flock|^fcntl'
>   fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
>
>   perl has used fcntl internally for its flock builtin for some time

OK, so I hadn't figured that out.  That's a very good thing, because
it means that my proposed changes to use perl 'flock' correctly would in
actual fact fix the bug.

It's not documented in the perl documenation that it uses fcntl for the
flock builtin, and in fact it's (falsely) documented that it uses flock.

I quote from perlfunc (1):
" Calls flock(2), or an emulation of it, on FILEHANDLE."

I hadn't gone to the effort of strace-ing perl or searching through its
source code to check whether the documentation was wrong!

Perhaps I should file a bug against perl.  :-P

Oh, and POSIX::fcntl isn't documented anywhere I could find; although the
POSIX module is intermittently mentioned, I couldn't actually find any
documentation for it.

So thanks for informing me of these undocumented facts.  :-)  Anyway, that
means that my proposal was even better than I thought it was.  :-)


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bug maintenance, last comment.

Brendan O'Dea
In reply to this post by Joey Hess
On Fri, Jan 06, 2006 at 08:48:15AM -0500, Joey Hess wrote:
>Nathanael Nerode wrote:
>> My analysis was that it's unreasonable to ask a program
>> written in perl to use fcntl
>
>That's weird, there's
>
>a) POSIX::fcntl

Which simply calls CORE::fcntl.

The fact that there is an entry point for the system call however
doesn't mean that it's reasonable to use however (see
http://lists.debian.org/debian-perl/2005/12/msg00044.html).

>b) strace perl -e 'flock(1, "/etc/passwd")' 2>&1 |egrep '^flock|^fcntl'
>   fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
>
>   perl has used fcntl internally for its flock builtin for some time

Which is an implementation detail that you probably shouldn't be too
concerned about.  On Debian/k*BSD you may find that a real flock is
used.

All of which is fairly irrelevant.  Exactly which kind of locking is
used shouldn't really make any difference so long as all processes
updating the file use the same mechanism.

Is install-info the only process which updates /usr/share/info/dir?  Or
does emacs also modify this file?

--bod


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bug maintenance, last comment.

Andrew Suffield
On Mon, Jan 09, 2006 at 10:58:54AM +1100, Brendan O'Dea wrote:
> All of which is fairly irrelevant.  Exactly which kind of locking is
> used shouldn't really make any difference so long as all processes
> updating the file use the same mechanism.

The important distinction is that fcntl locks across all NFS clients
to this file, while flock only locks the local system.

--
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc (196 bytes) Download Attachment