Bug#920039: RFS: brightness-controller/2.2.3 [ITP]
On Tue, Jan 22, 2019 at 04:57:20PM +0530, Archisman Panigrahi wrote:
> I am not sure about the native package issue. Has it got something to
> do with /debian/source/format? I did not exactly understand what is
> the difference between native and quilt, so went for native. Any
> suggestion is welcome.
The "native" format is adequate only when there's no separate upstream (and
often not even then); in this case you are packaging Amit's software that
has proper releases, tarballs, and all proper trappings.
The packaging is supposed to be composed of two pieces:
* the upstream (.orig) tarball
* a packaging tarball, that includes the debian/ dir and a (possibly empty)
patch series
This was somewhat different with the 1.0 format, but you don't want it --
even if you (like me) despite quilt, the "3.0 (quilt)" format with a single
patch is strictly better than 1.0.
> No such executable file is needed to run this software. The
> /usr/bin/brightness/controller calls the file
> /usr/share/brightness-controller/init.py (which has been marked
> executible with chmod +x), which can calls python to run itself.
Yeah, but you're supposed to install the executable into /usr/bin. What
your current package does is a text file without the +x bit, that's not
going to work. In some complex cases it might be reasonable to have a
wrapper but here I don't see a reason to not install to /usr/bin directly.
In any case, a script needs to declare a hashbang with an explicit
interpreter -- even though shells can execute a script without such a
hashbang, relying on this is not allowed in Debian as it'd be unreliable if
the user's shell is something weird.
> I am not the main developer of the software (Amit Seal Ami
> <amitsealami@gmail.com> is), but am one of the major contributors. My
> name is included in the list of contributors under
> /usr/share/brightness-controller/about.py.
All copyright holders (ie, contributors with non-trivial parts) need to be
listed or at least referred to.
> Can I edit the package description (to remove license information,
> etc.) and release the next version? Would that work, or do I have to
> make another RFS for it?
Yeah, please do. You're not supposed to bump the version number while doing
so (unless there's a really good reason), and neither you need another RFS.
You can update this one until an upload to the archive has actually happened.
> And, this is not compatible with Python 3 yet.
That's good for Buster but it'll need to be updated after.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄⠀⠀⠀⠀
Reply to: