Re: Filename conflict: /usr/bin/dstat (dstat and sleuthkit)
On Fri, 26 Nov 2004, Andrew Pollock wrote:
> I'm sending this note as per policy 10.1 regarding packages shipping files
> of the same name with different functionality.
>
> I recently packaged dstat[1], and after it was accepted, an RC bug was filed
> because sleuthkit already provided a (completely unrelated) /usr/bin/dstat
> (my bad for not checking beforehand).
This is embarassing, because I package sleuthkit myself and I did not
notice it. I looked on freshmeat and checked the name via google, and
except some references to variable names in programs and pages about
descriptive statistics it did not give any conflicts.
> Given that dstat is the name of the upstream software, I think renaming the
> /usr/bin/dstat provided by the dstat package is a bit suboptimal. I'm
> wondering if renaming the /usr/bin/dstat in sleuthkit to something else
> (nothing is immediately jumping to mind, but the description in the manpage
> is "Display details of a data structure (i.e. block or sector)".
I guess it is like fstat for disks.
> To be honest, it's not immediately obvious (to me) why the dstat I've
> packaged is called dstat (other than the author's name starts with a D),
> either, so I'll float the idea of renaming it with the upstream author.
Well, I have some other tools starting with D, so yes. :) And it is short,
falls in the {vm,io,if}stat category and it sounds nice too for a general
purpose tool. I can't think of a better name, otherwise I would already
have been using that one. My requirement is that it ends with stat, but
nothing comes to mind that would give it more meaning by prepending one or
2 characters.
> In the meantime, I've uploaded a new version of dstat that conflicts with
> sleuthkit.
Well, obviously I would rather not change the name. It might have been
easier a month ago.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]
Reply to: