Author Topic: Packaging advice  (Read 3984 times)

mhall119

  • Newbie
  • *
  • Posts: 1
    • View Profile
Packaging advice
« on: February 16, 2015, 01:16:38 PM »
Thanks for supporting us Linux users!

Just briefly checked your .deb package and have a couple of recommendations:

  • Don't make user folders in your postinst script, this is run only once, and as the root user. If you need to create things in the user's space, it's best to do that the first time the user runs the application
  • Create a meshmixer.desktop file to make launching it from the desktop menus possible (rather than from the commandline). The full spec for this file is http://standards.freedesktop.org/desktop-entry-spec/latest/ but you typically only need a small number of lines to describe and run your application. This file should be installed to usr/share/applications/, then it will be visible in the user's application menu

If you want additional help you can join the #ubuntu-devel IRC channel and get live help from experienced Ubuntu packagers.

Good luck, I look forward to seeing more released from you guys in the future!

RMS

  • meshmixer founder
  • Administrator
  • Hero Member
  • *****
  • Posts: 1238
    • View Profile
    • gradientspace
Re: Packaging advice
« Reply #1 on: February 16, 2015, 04:24:46 PM »
Thanks!! Will check out the IRC channel.

The user-folders issue is also a problem we have on win and OSX, we are working on a general fix for this.
created meshmixer - now starting gradientspace - meshmixer consulting available http://www.gradientspace.com/consulting

revast

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: Packaging advice
« Reply #2 on: February 17, 2015, 08:31:08 AM »
I have made a package with my proposed changes already builtin: http://openartist.org/debian/trusty64/meshmixer_2.7-1_amd64.deb

-dev dependencies are not needed for release package, I removed them. there are no .so.3 packages, also removed.
I renamed meshmixer to meshmixer.real and made a meshmixer shell-script to start mm indirectly, I put in the things of postinst except ldconfig, repoconfig into the meshmixer shell-script. I made a (deactivated) prototype in postinst with zenity to ask first before adding the repository, people like to know when a new software source gets added into their system.

I made a .desktop file in /usr/share/applications, and made a .png icon out of the .ico file in resources, put  it into /usr/share/pixmaps. As you hopefully all know, there is a big difference of having one application debianized and of having it in the official repositories - this is much more work. Lintian... This one is now ready to be installed from my perspective - other people like to have signed repositories and debian packages - which is not too much more work, but nice to have. For this purpose, I would look into aptly

In general, it would be way better to put everything into /opt and just have a shell script starting the app residing in /usr/bin
That's just my opinion though.
« Last Edit: February 17, 2015, 09:18:30 AM by revast »

RMS

  • meshmixer founder
  • Administrator
  • Hero Member
  • *****
  • Posts: 1238
    • View Profile
    • gradientspace
Re: Packaging advice
« Reply #3 on: February 17, 2015, 10:11:19 AM »
wow. thanks!!
created meshmixer - now starting gradientspace - meshmixer consulting available http://www.gradientspace.com/consulting

ayourk

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: Packaging advice
« Reply #4 on: March 10, 2016, 02:22:54 PM »
Thanks for supporting us Linux users!

Just briefly checked your .deb package and have a couple of recommendations:

  • Don't make user folders in your postinst script, this is run only once, and as the root user. If you need to create things in the user's space, it's best to do that the first time the user runs the application
  • Create a meshmixer.desktop file to make launching it from the desktop menus possible (rather than from the commandline). The full spec for this file is http://standards.freedesktop.org/desktop-entry-spec/latest/ but you typically only need a small number of lines to describe and run your application. This file should be installed to usr/share/applications/, then it will be visible in the user's application menu
...

Here are some of my recommendations:  Not everyone uses .desktop file compatible window managers.  I suggest including a "menu" file in your package too.  The Debian "menu" files are universal and if I recall correctly can even generate .desktop files.  One way to autogenerate a sample .menu file is via debhelper using dh_make.  You can do this with a simple sample package by doing the following:

Code: [Select]
# mkdir sample-1.0
# tar -zcf - sample-1.0 > sample_1.0.orig.tar.gz
# cd sample-1.0
# dh_make -C s
Maintainer name  : unknown
Email-Address    : you@yourdomain.com
Date             : Thu, 10 Mar 2016 12:05:59 -0700
Package Name     : sample
Version          : 1.0
License          : blank
Type of Package  : Single
Hit <enter> to confirm:
Skipping creating ../sample_1.0.orig.tar.gz because it already exists
Currently there is no top level Makefile. This may require additional tuning.
Done. Please edit the files in the debian/ subdirectory now. You should also
check that the sample Makefiles install into $DESTDIR and not in / .

This will give you a debian/ folder in sample-1.0 that you can peruse and see what template files exist.  One example template file is debian/menu.ex.  This is the example I'm describing.

Here is an example .menu file for meshmixer that I whipped up based on your .desktop file:

Code: [Select]
?package(meshmixer):needs="X11" section="Applications/Graphics"\
  title="MeshMixer" longtitle="Mesh processing"\
  description="Application for aggregating, fixing and editing meshes, and for preparing them for 3d printers."\
  command="/usr/bin/meshmixer %F" icon="/usr/share/pixmaps/meshmixer.png"

One way you can provide a source package to us would be to have the precompiled binaries in the source tarball and then have all the debinization as separate patches.  I've seen this done for things like google-earth, teamviewer and a few other packages where the full source code can't be released.