How to create pet from compiled application?

[geo_c]

In the past couple months I've compiled a few applications from source against fossapup.

My question is: Is it possible to create a pet package of an application once it's compiled and installed?

My list of compiled apps is:

nmail - email client
neomutt - email client
ncmpcpp - music player front-end to mpd server
ninja - compile environment
wordgrinder - word processor
micro - text editor
frecobaldi-3.2 - lilypond file editor
python-ly-0.9.7 - lilypond python library
calcurse-4.8.0 - calendar organizer

The pets would be mostly for myself, as to be able to install them on a fresh system.

[HerrBert]

From what i recall you can create a pet file easy, if your Makefile supports the DESTDIR variable.
Create a directory for the install files, run make DESTDIR=</path/to/install_files> install, cd to one level
above </path/to/install_files> and run dir2pet from commandline...

[geo_c]

run make DESTDIR=</path/to/install_files> install, cd to one level
above </path/to/install_files> and run dir2pet from commandline...

So if I'm understanding correctly, basically run the compile to a directory and make a pet out of it.

Will it grab the dependencies that I had to load into the OS and include them in the pet?

[HerrBert]

Dependencies you installed for compiling will not be included in the pet file.
You can specify dependencies in dir2pet. But this doesn't make sense, if you
use your pet locally. petget will not download and install them...

Otherwise you have to add additional installed packages manually.
No easy way, but can be done.
Packages/dependencies installed via PPM or petget are logged in
/var/packages/<packagename>.files
Copy the files listed in the .files file from /initrd/pup_rw to </path/to/install_files>

[mikewalsh]

@geo_c :-

Sure. It's entirely possible to make a .pet package out of almost anything.

How well do you know your Linux file-system structure?

A functional package will usually contain certain 'standard' items:-

• An executable 'binary' or script that starts the application - usually in one of the user 'bins'.....either /usr/bin or /usr/local/bin.

• Shared dependencies - if required - either in /lib or lib64 OR /usr/lib OR /usr/lib/64. Unfortunately, if Ubuntu-based you then also have to decide whether to place them in x86_64-linux-gnu (this is Canonical's workaround for multiarch stuff, rather than simply using /lib or lib64 like everybody else). Gets unnecessarily complicated, REAL fast.

• Any related global config files go in /etc

• User config files can either go in $USER/.config or simply IN $USER. In Puppy, of course, $USER is /root.

• For a Menu entry, a .desktop entry in /usr/share/applications.....and the easiest place for icons is in /usr/share/pixmaps. Creating an entire working set of strictly size-related icons for /usr/share/icons quickly becomes horrendously complex, despite this being the accepted, 'standard' method of doing so. Mostly related to standard file-path layouts for community-wide 'standard' full desktop environments, ensuring there's a correctly-sized icon for absolutely EVERY eventuality...

• You can use a file called 'pinstall.sh' to carry out certain instructions AT install time.....for instance, placing an executable icon in the tray. Etc., etc....

That's the basics.

----------------------------------------------------

You'll need to create a directory containing everything you want to put in the pet, creating everything needed. For example, if you want a .desktop entry in /usr/share/applications, you'll need to do something like this:-

• Create an empty directory, /usr (unless it already exists n the build directory)

• Inside that, create an empty directory, /share (unless it already exists)

• Inside that, create an empty directory /applications (unless it already exists)

• And inside that, create a blank text file - called xxxxxxx.desktop.....into which you will then need to write all the correct lines that go to make up a working Puppy .desktop entry.

That's just one item.

Easiest way to get the hang of building your own packages is to extract any other Puppy .pet, and study how it's been constructed. Package-building is one of those things for which it's almost impossible to give a detailed set of step-by-step instructions, simply because it's different every single time. Those of us who build a lot of packages, we all learnt via trial & error, making plenty of mistakes as we did so, but learning from those mistakes.

You're trying to mimic the layout of the existing file system, putting all the necessary parts of your package into the relevant locations. Make sense?

Mike.

[geo_c]

@geo_c :-

You're trying to mimic the layout of the existing file system, putting all the necessary parts of your package into the relevant locations. Make sense?

Mike.

Looking at the compile directories of the source compiles I've done, I started to get that concept. But then a script is needed to actually put those files into the system file structure, no? Or does extracting a pet package automatically copy the directory structure within the pet to the corresponding system directory?

[mikewalsh]

Once you've built your .pet package, simply clicking on the .pet package will cause petget to spring into action......and petget will take care of installation for you, putting everything where you've told it to put the components of your package. All the necessary scripts are taken care of for you, courtesy of former forum member mavrothal.

(Petget, in case you wondered, is the mechanism behind the PPM, amongst other things).

I've never investigated, but I presume there's a mime-type somewhere that causes petget to recognise a .pet package. Package-building is its own type of art-form.....and in its own way is just as elegant as many of the other activities various Puppians subscribe to & engage in.

This is what makes our community work. We each contribute, in our own way, according to our interests/enthusiasm/abilities.

Mike.

[geo_c]

Once you've built your .pet package, simply clicking on the .pet package will cause petget to spring into action......and petget will take care of installation for you, putting everything where you've told it to put the components of your package. All the necessary scripts are taken care of for you, courtesy of former forum member mavrothal.

Mike.

So if I make the pet like that, I suppose I could make pet's for all the necessary dependencies the same way, by either downloading from the repo, or compiling from source and using dir2pet.

If that's a good approach, I'm seeing some light at the end of the tunnel, as every source package lists the necessary dependencies, correct?

[williwaw]

following the discussion with interest and have a possibly related question.

some compiles are said to be static. Isn't that including needed dependencies within the app?

I am thinking of this as a possibly way to compile, say for instance, nmail as a portable.

[puddlemoon]

So if I make the pet like that, I suppose I could make pet's for all the necessary dependencies the same way, by either downloading from the repo, or compiling from source and using dir2pet.

If that's a good approach, I'm seeing some light at the end of the tunnel, as every source package lists the necessary dependencies, correct?

It is also reasonable to combine unique dependencies with their respective pet IMO (keeping in mind they won't show up in ppm independently). This is how I have made some sfs, namely my ydrv has deps unique to Mixxx so it can be loaded and unloaded with all it's "baggage" and more touching on the portable concept. Can always use listdd on a binary when in doubt to find missing ones.

some compiles are said to be static. Isn't that including needed dependencies within the app?

AFAIK yes, static builds don't look outside for shared libs or other deps
For dynamic builds I also often use --prefix=/usr when configuring makefiles so as to keep a simple packaging structure.

[mikewalsh]

@geo_c :-

For 'static' compiling, this might come in useful:-

https://insanecoding.blogspot.com/2012/ ... aries.html

Hope it helps.

Mike.

[geo_c]

@geo_c :-
For 'static' compiling, this might come in useful:-
ttps://insanecoding.blogspot.com/2012/07/creating-portable-linux-binaries.html
Hope it helps.
Mike.

When I run the ldd command from root, it doesn't matter what application I provide as an argument, it's returning 'no such file or directory.' So do I need to find the binary and try to run it from that directory?

[mikewalsh]

@geo_c :-

Either open a terminal in the directory where the binary is - usually /usr/bin OR /usr/local/bin.....sometimes /usr/sbin - or, if opening a terminal in /root, you MUST give the full $PATH to the binary. If you want to check the dependencies for, say, Abiword, you would either open a terminal in /usr/bin, and enter

Code: Select all

ldd ./abiword

.....or if opening a terminal in /root, you would need to enter

Code: Select all

ldd /usr/bin/abiword

You can open a root terminal and start an app by simply entering the name of the binary, but when checking for dependencies, if you're anywhere else outside the directory containing your binary, ldd (the 'linker') needs to see a full $PATH to it. Otherwise, it doesn't know where to look, and assumes you're checking whatever directory you're in at the time.....

I think that's right, anyway. It's how I usually approach things. Others may be able to explain it better than I can.....

Mike.

[geo_c]

@geo_c :-

Code: Select all

ldd ./abiword

.....or if opening a terminal in /root, you would need to enter

Code: Select all

ldd /usr/bin/abiword

Great, now I can see dependencies. I'm thinking that trying a static build is going to be way too tricky to start.

My thought process seems to be going in circles, so let me back up.

• I want to create a pet to install an application on a fresh fossapup

• I currently have that application compiled and installed on my pupsave system

• To create the pet, I can list the dependencies from my pupsave, copy them to the new pet directory, boot a pristine version of fossapup, and compile and install the application to that same directory, dir2pet, and have a pet that will install on the clean system.

Or is that not even close?

[mikewalsh]

@geo_c :-

TBH, if you're going to be installing it in the same Puppy every time, and you've already compiled it, you've got the hard work out of the way. You don't need to keep re-compiling it every time.

All you now need is to work up a .pet package to speed-up installation on subsequent fresh installs. This is the easy part.

You'll need to check what dependencies are "unique" to the application in question; in other words, list the dependencies via 'ldd', then check that list against a 'vanilla' install of Fossapup to see which, if any, are not included in a fresh Fossapup install.

Those will be the only ones you need to add to your package. Easiest way; boot into a 'clean' Fossapup, then 'ldd' the binary. It'll list what's missing. That's what will be needed to make a working .pet package for your requirements......since you only want it for yourself, it'll be simpler than if you're trying to build a package to publish for everyone else.

I do a lot of this. I have a ton of 'personal' pets that wouldn't work for other folks anyway, since they're all tied-in to things I've constructed for my own personal use......many of which are common, 'shared' applications that I use throughout the kennels.

Pudlemoon's comment about packaging libs together with your application is bang on the nail. I go to great lengths to ensure that what I build is a simple, 'one-click' affair to install; click to install, and it's ready to go. Which is, I believe, what you want.

Mike.

[geo_c]

some compiles are said to be static. Isn't that including needed dependencies within the app?

AFAIK yes, static builds don't look outside for shared libs or other deps
For dynamic builds I also often use --prefix=/usr when configuring makefiles so as to keep a simple packaging structure.

So I ran ldd on Frescobaldi which I installed with a debian package and added dependencies from the ppm. ldd returned: 'frescobaldi is not a dynamic binary' meaning that the package is more or less static?

I believe to install frescobaldi with the debian-pkg I had to install some pythonqt5 bindings, python3-poppler, python3-pygame. But since I installed those independently of frescobaldi, are they somehow not listed as dependencies?

[puddlemoon]

@geo_c
I checked out frescobaldi, seems the file in */bin is actually a python script not a binary executable, hence the message. fortunately for that one the list of requirements is clear in the read me. In fossa, right click on a binary will offer to open with listdd but not for .py or pearl scripts etc... So frescobaldi has requirements to run but not dynamically linked shared libs.

[geo_c]

@geo_c
I checked out frescobaldi, seems the file in */bin is actually a python script not a binary executable

Yes, you're right, I kind of forgot. It's the first package I ever installed without using the ppm. Thanks for checking that out. Fortunately I saved a list of the required framework for that one.