[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

On Sat, Nov 24, 2007 at 09:34:21PM +0530, Kartik Mistry wrote:
> > Kartik what possible reason did you have for overriding the lintian
> > error report, rather than changing your package to remove the error?
> linhdd introduce binary abs_fdisk which was modified copy of fdisk
> from new version 0.4. It was arch:all before that too, and previous
> maintainer set it to arch:all saying 'it will save achieve space'.

So first, you're the maintainer of that package now -- if something
the previous maintainer did no longer makes sense because of changes
since then, it's your responsibility to fix that. If you're not sure
whether the old behaviour makes sense, then talk to people about it --
the previous maintainer, your sponsor or AM, debian-mentors, or whatever
else. Better to ask a stupid question early, than upload something broken
to the archive.

Or, well, at least you _were_ the maintainer...

> Since, it was working fine with 0.3, linhdd now depends on modified
> copy of fdisk, abs_fdisk. I fixed this by adding upstream provided
> copy of it.

Right, which also had the bug that abs_fdisk wasn't being built from
source; which could have meant, eg, that the source wasn't complete and
thus couldn't actually be used to build the binary, or that the binary was
trojaned or infected by a virus. Either way it would've meant any security
bugs in the binary would have been difficult to fix because the security
team would need to change your build system as well as patch the source.

> > Did you ask anyone's advice before [introducing the lintian override]?

You haven't answered this.

The lintian error *should* have been enough to give you serious concerns
about what you were doing; if you addressed that by asking for advice,
and got bad advice (or didn't get an answer at all), that's one thing;
if you addressed it by just ignoring the hint (which is what it looks
like), that's a problem that you should be correcting.

> > Why are you asking for the
> > removal of linhdd now (Bug#452629), instead of *fixing* the package,
> > eg, by making the package architecture specific instead of arch:all and
> > either the binary built as part of debian/rules, or simply using the
> > fdisk that's already packaged as part of util-linux?
> As suggested to me, I did removal of linhdd. To fix this bug, we have
> to build util-linux and I think its too much and probably wrong to
> have fdisk stay in /usr/bin.

The social contract says "we will be guided by the needs of our users",
amongst other things. Linhdd obviously has at least one user, based on
Bug#442093 -- wouldn't the needs of the Debian users that have installed
linhdd be better served by fixing the problem, than removing the package?

Fixing the problem you have an RC bug on (452464) would've just required
an upload with Arch:all changed to Arch:i386, and the removal of the
lintian override.

Given the description of abs_fdisk on the linhdd site:

] 0.4 release now includes a customized version of fdisk (called
] abs_fdisk). Why? Well, daealing with SATA (scsi) in /proc was a bear --
] and the ease with which fdisk gave me the needed drive info made me wish
] I could use fdisk. Just that on Slackware and Absolute, which I use,
] you can only run fdisk as root. Sooooo -- I downloaded util-linux and
] changed the source code for fdisk so that it would not srite anythig
] to drives, just return the drive info. Renamed it abs_fdisk (because I
] wrote it sort of specifically for Absolute Linux, and Eureka!, Use fdisk
] as non-root user safely.

makes it sound to me like you should be packaging abs_fdisk separately and
having linhdd Depend: on it; or, ideally, getting util-linux patched so
its fdisk can support the same features as abs_fdisk.

Just getting the package removed seems like taking the easy way out to
try to make the issue go away instead of actually fixing the problem
(which is what introducing a lintian override seemed like too)...


Attachment: signature.asc
Description: Digital signature

Reply to: