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

Bug#998041: RFS: makedeb/11.0.1-1 [ITP] -- The modern packaging tool for Debian archives



Sorry, this must've gotten overlooked on my end, I didn't see this email until just now.

That first Lintian error definitely could be fixed, I would've sworn we had that implemented but I guess not.

> you are packaging arch:all but have hard-coded arch-dependent settings for amd64. Is this intentional?

That is not, no. I'm assuming it got overlooked as most users of makedeb use amd64 as their system architecture, but the core functionality of makedeb that utilizes architecture-specific features (such as architecture extensions on certain variables) is working fine (presumably, I know of one group that uses makedeb that builds for multiple architectures off the top of my head).

> I don't think that should be a script  needing a shebang, should it?

I don't think it probably needs that, no.

Both of these problems appear to be from when we ported makepkg from a binary release from the Arch Linux archives, and these issues must've slipped in. Again, I'm assuming they've gotten overlooked simply because they haven't caused any major issues for makedeb's user base. I'm not saying they don't need fixed, and I'll definitely look into getting them in such a state.

> Somewhere in the documentation it still says "the modern packaging tool for Debian archives"

> Another package, zotero, claims "zotero is not available for the 'x86_64'
architecture.**"

I think this is an issue with an out of date version of makedeb being present on Debian mentors. The Debian packaging on makedeb's end hasn't received the care it needs lately, and that's all on me.

> Is there (automated) QA?

There is not, no. We could probably integrate lintian into built packages, though again, not many users have complained about it, so I guess it hasn't posed to be much of an issue yet.

I'm not gonna deny for a second that there isn't stuff that needs improved, there definitely is. I know all of this hasn't been the best experience, but I'm sorry about all of that, and I'll make sure progress is made here to improve.

--
Hunter Wittenborn
hunter@hunterwittenborn.com

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


Reply to: