[SOLVED] Make a debian package

[CuriousMeow]

I've been reading a lot of documentation about how to make a deb package. It doesn't seem to be very complicated, it seems to be a matter of "placing the right files at the right place". However, I'm not sure if I have got everything right. I will be testing first with some "Hello world" kind of demo file, but I still am unsure of a few things and have a few questions. So, a bit of help and advice would be appreciated.

So, based on what I've read and what I've understood, I should go with a file tree like this :

debfiletree.png (20.72 KiB) Viewed 928 times

Since the main settings (which version of Python interpreter is needed, the dependencies) should be indicated in the setup.py file, I think the "rule" file in the Debian folder is not needed. Is that correct ?

Does it look right ? Is there something I'm forgetting or should know about ?

Another question is : I've noticed that when installing a deb package from the software manager, I can find the software in the Linux Mint menu, but when installing a deb package I've downloaded from the dev websites (even if it's the very same software), it won't be added in the Linux Mint menu. How do I make it so the software will be in the menu after it's been installed ? Do I need another file or something else ?

[CuriousMeow]

Nobody knows ?

Looks like I got confused, after reading more documentation, I figured I do need to add a "rule" file in the DEBIAN folder, and a few other files. This part is quite covered, I should be good with the documentation.

But I'm still a bit confused about the dependencies though : I need to declare them in both setup.py and control, right ? Isn't that redundant ? Does it matter ?

Hope someone who knows about this can give me a bit of insight/advice.

[Pierre]

that tree looks about right.

it's your application.dependencies that would be critical, especially if your application calls them from elsewhere.

[AndyMH]

There is a bit more in this post on building your own deb:
viewtopic.php?f=47&t=317954
As far as your original structure is concerned, it is only approximately correct, e.g. you would normally put executables in one of the existing bin or sbin folders, or maybe in opt with a symlink and .desktop files live in usr/share/applications.

But I'm still a bit confused about the dependencies though : I need to declare them in both setup.py and control, right ? Isn't that redundant ? Does it matter ?

You need to declare them in the control file, if you don't and a package isn't installed your application won't work. If you list the dependencies and a package is not installed then the package installer will install it for you.

[CuriousMeow]

As far as your original structure is concerned, it is only approximately correct, e.g. you would normally put executables in one of the existing bin or sbin folders, or maybe in opt with a symlink and .desktop files live in usr/share/applications.

Ah, that's actually why I've made this topic. I have indeed read in tutorials and documentation that the script file should go in the bin folder. But when it comes to Python, most tutorials I've read were using the structure I've posted in the picture. That was a bit confusing.

Does it mean I just need to move the "myapp" folder (with the script file in it) to usr/bin ? And just leave setup.py where it is ?

You need to declare them in the control file, if you don't and a package isn't installed your application won't work. If you list the dependencies and a package is not installed then the package installer will install it for you.

Ok, got it.

[AndyMH]

Does it mean I just need to move the "myapp" folder (with the script file in it) to usr/bin ? And just leave setup.py where it is ?

You have choices, put the myapp script somewhere in your path, to find out what it is in a terminal echo $PATH. If you leave it in the myapp folder (even if you move the folder into /bin) the user won't be able to execute myapp, they will need to enter the full pathname to myapp. Alternatively, you could modify the path to include the path to myapp script. It lives in etc/environment. What is bad practice is to mess with the user's home folder in a deb.

[CuriousMeow]

If you leave it in the myapp folder (even if you move the folder into /bin) the user won't be able to execute myapp, they will need to enter the full pathname to myapp.

Ok, got it.

I've made a new file tree, if I got everything right, it should be correct, right ?

Although, now I'm confused : I've tried to search for where to place the setup.py file, but the tutorials I've seen didn't have one at all. They didn't even have an __init__.py either. In other tutorials (with the structure of the 1st picture), there were both setup.py and __init__.py. So I'm confused, are they needed or not ?

[AndyMH]

Icons usually live in /usr/share/icons. If you put it in there you shouldn't need to specify the full pathname to it in your .desktop file.

No idea what your setup.py or init.py do, but I'd be tempted to create a folder /opt/myapp and put them in there along with the license.txt. However when those scripts get called, you will need to specify the full pathname. With your current structure, setup.py will get copied into / when you run the deb, not what you want.

Remember, the myapp folder, when you build the deb, gets treated as /. Apart from the DEBIAN folder, everything in there gets copied into the user's / filesystem in the same places as you put them in the myapp folder.

[CuriousMeow]

No idea what your setup.py or init.py do, but I'd be tempted to create a folder /opt/myapp and put them in there along with the license.txt. However when those scripts get called, you will need to specify the full pathname. With your current structure, setup.py will get copied into / when you run the deb, not what you want.

Well, setup.py is a bit like the control file of the Debian folder. I need to read more documentation about this and check whether it's actually needed or not in a debian package.

Thank you so much for your answers, it helps a lot.

[AndyMH]

Good luck! To build your deb:

Code: Select all

dpkg-deb --build /home/you/myapp

and it will dump the deb file in /home/you.

[CuriousMeow]

Good luck! To build your deb:

Code: Select all

dpkg-deb --build /home/you/myapp

and it will dump the deb file in /home/you.

Thank you ! I still have a bit of road ahead, though. Step 1 was to figure and comprehend the structure needed, step 2 will be to properly look into the files from the DEBIAN folder, to comprehend how everything works and fill them properly. Step 3 will be testing with a simple test script.


I've made a final file tree :

I've removed the setup.py file altogether (since it shouldn't be where I placed it in the previous trees and since in newer tutorials I've seen, it's not included at all), having an __init__.py then doesn't make sense here, with a single executable script, so I removed it from the file tree as well.

[AndyMH]

All you have to do now is try it and then fix the errors . Note, for foxclone, my DEBIAN folder only has control, preinst and postinst in it, the rest is optional. In fact the only mandatory item in there is control.

[CuriousMeow]

All you have to do now is try it and then fix the errors . Note, for foxclone, my DEBIAN folder only has control, preinst and postinst in it, the rest is optional. In fact the only mandatory item in there is control.

It worked !

I've tried a simple one, without dependencies (other than python3), with no "maintainer script". Now I'm pondering here : I wanted a desktop shortcut to be installed with the package. Some do, so I knew it was possible. So I searched for it, and it's something that should be added in the postint file. But, what I've learned is it should work just fine on Mint but might create issues on other distros. So I think I'll just not do that. The app appears in the menu anyway, I just needed to reboot the computer for it to appear on there. If a user wants a shortcut on their desktop, they'll add one themselves, I guess.

So I'm thinking about whether I want to add any of those files (preinst, etc) in my package. What I've read seems to mean the same kind of issue (as for shortcuts) could appear with scripts to uninstall older versions... Also, I am absolutely not familiar with the language those scripts should be written in and those scripts are not something that should be messed with.

So, I'm pondering. Maybe I'll just not add any of those files and if I want to make a software that will be upgraded along time, I'll go with MyApp, then MyApp2, then MyApp3 and make it so the installer won't recognize it as a new version of the previous one, so that their install won't be blocked, and let the users remove the old version themselves ? Is that a ok thing to do ?

[AndyMH]

I also thought about putting a shortcut on the desktop and then didn't - first I couldn't find out how to reference the user's home folder - /home/$USER did not work in a script and second, the advice I found on the web was that it was bad practice to make changes to the user's home folder in a deb. It was apparently okay for myapp to make changes to the user's home on first run, e.g. creating config files.

As for updating myapp to myapp2, etc. This is what you can/should use preinst for - to get rid of the old version. If you look at the link I gave you early on, you will find in there the script I had for preinst to delete old versions of foxclone. It tests for the existence of foxclone* and if found deletes the old files. Scripting you do with bash, not one of my strengths but lots of info on the web and if stuck, ask on the forum, there are many more knowledgeable than me in the arcane ways of bash (I always trip up on syntax).

On dependencies, you may stumble. An example, foxclone uses mkdir, but you can't list that as a dependency, you need coreutils which is the package that contains mkdir. Others are easy, parted is in the parted package. Google is your friend here - you need to list every linux utility myapp uses and then search to find out what package it is in. Or just put it in the control file and it will tell you if you got it wrong when you try to build it.

Note - you are only getting this advice because I generated my first deb a couple of months ago, I'm only slightly ahead of you

[CuriousMeow]

On dependencies, you may stumble. An example, foxclone uses mkdir, but you can't list that as a dependency, you need coreutils which is the package that contains mkdir. Others are easy, parted is in the parted package. Google is your friend here - you need to list every linux utility myapp uses and then search to find out what package it is in. Or just put it in the control file and it will tell you if you got it wrong when you try to build it.

Indeed. It's easy to get confused or use the name of the module instead of the name of the package.

Note - you are only getting this advice because I generated my first deb a couple of months ago, I'm only slightly ahead of you

Ah, I'm lucky, then. Your advices were needed and appreciated.

[CuriousMeow]

Oh no, I've encountered a problem now...

I've made my debian package, installed it on the same computer I used to make it. Everything is fine, perfect, and all. I went to install it on another computer, the dependencies installed just fine it seems, but then bam, unable to install the package.

The error I get is :

"myapp.deb has premature member 'control.tar.xz' before control.tar.gz', giving up"
" subprocess dpkg --control returned error exit status 2"

When trying to open myapp.deb from the archive manager, it gives the same error (the first line above). I don't know what it means really. I'm confused, as the package works perfectly on my other computer and I don't get an error on that computer when opening myapp.deb from the archive manage. I don't have another computer to try it on right now.

Edited to add : the test debian package I've made last time works on both computers. I think I haven't done anything different but use the other computer to make the package this time.

[AndyMH]

https://askubuntu.com/questions/1065231 ... tr/1100361

[CuriousMeow]

https://askubuntu.com/questions/1065231 ... tr/1100361

Oh... I haven't tried the solution yet, but I'm wondering, I'm not the only one who will stumble on this problem, then. Should I just make packages on the old computer to make sure it runs everywhere (is that even the case ?) ? Or should I update and other people still using 17.3 will be unable to install the packages (unless they fix it too) ? (Or did I understand things wrong ?)

[AndyMH]

You should aim to make the deb work on every ubuntu linux. If you build it on say LM19.3, you might get a dependency problem with an older version, e.g. LM17.3 along the lines of "requires libxyz > V1.2", V1.0 installed. Only one way to find out...

The link was the first hit I got googling on your error. The other way would be to keep removing the dependencies in the control file one by one, rebuilding and then testing on the problem PC to see if the problem goes away, i.e. what package is causing the problem? Will take some time, but that's what testing is about.

[CuriousMeow]

You should aim to make the deb work on every ubuntu linux. If you build it on say LM19.3, you might get a dependency problem with an older version, e.g. LM17.3 along the lines of "requires libxyz > V1.2", V1.0 installed. Only one way to find out...

The link was the first hit I got googling on your error. The other way would be to keep removing the dependencies in the control file one by one, rebuilding and then testing on the problem PC to see if the problem goes away, i.e. what package is causing the problem? Will take some time, but that's what testing is about.

Well, there are only 2 dependencies in my package (python3, which supposedly is already installed on most computers and python3-tk, which is not installed on most computers). Again, when trying to install, the dependencies were installed just fine, but the install didn't go through. Although, for some reason, another dependency (linked to python3-tk) was in the list of dependencies and was installed too, when I didn't list it in the control file and didn't even know about it. So I don't think the dependencies would cause an issue ?

I'm going to repackage it on 17.3 and see if it works on 19.3 (it did with my test package last time), I haven't had time to try yet.
I'm probably not the only person who still uses an "old" computer with the original distro installed and which is lacking of upgrade of stuff (like what is explained in the topic you've linked). I think most people seeing this kind of error would think the package doesn't work and move on... Unless they really want to use it.
As long as making the package on 17.3 doesn't cause any issue or security concern, I think I'm going to go with that at least for a while. Or at worst I'll make 1 on each and let people see which one works for them ?