How to add to or remove applications from the default build

[mikeslr]

Maybe skip down to the next post and come back after reading it.

Sorry, but my ability to learn languages --even bash-- is limited. I can get the 'gist' of what the various sections of scripts do, but haven't been able to identify a particular section of code which would have to be edited to have a pet (not obtained by 'woof' itself) incorporated into a build; nor --for that matter-- remove applications woof scripts would include by default.

These questions came up (again) as I was attempting to build an updated version of xenialpup64. (Don't ask ) 2createpackages generated an error message that read:

"ERROR: 'jwmconfig3' package does not exist.
You will need to find a matching package and place in packages-pet,
or packages-deb-xenial as appropriate.
Do it, then rerun this script and choose to build jwmconfig3.

ERROR: 'syslinux_xenial' package does not exist.
You will need to find a matching package and place in packages-pet,
or packages-deb-xenial as appropriate.
Do it, then rerun this script and choose to build syslinux_xenial."

I was able to easily "find" those packages. I booted into my current version of Xenialpup64 and ran gnewpet*. https://www.forum.puppylinux.com/viewto ... 211#p73211. And I found a logical place to put the resulting pets: /local-repositories/x86_64/pet-packages.

But does the 2createpackages script 'index' pets it finds there and then use that index; or was there some earlier part of the scripts which created such 'index'; or something else?

Actually, it gets a little more complicated. I ran gnewpet twice, once selecting 'woof-match'. So I ended up with 3 pets: jwmconfig3-151025.pet, syslinux_xenial-4.07-x86_64.pet and syslinux_xenial.pet. Not sure if there's any difference between the latter two. But it does matter if 2createpackages is using a pre-existing index specifying a pet with one suffix --like -151025.pet-- while the pet placed in pet-packages has no, or a different, suffix.

Similarly, examining what pets were now located in local-repositories/x86_64/pet-packages revealed (for example) abiword-3.0.1-x86_64.pet plus a lot of 'dev' and 'doc' pets. I never use abiword; and when installing or creating pets via PPM usually choose to 'strip' 'devs' and 'docs'. Would just deleting pets from that folder suffice, generate error messages which could be ignored, or something else such as having to edit some already existent 'index'?

Along the same lines, I noticed the companion /local-repositories/x86_64/packages-deb-xenial has debs such as /libjasoncpp-dev_1.7.2-1_amd64.deb. I'm less certain that Ubuntu's 'dev' packages aren't as unnecessary for ordinary daily usage a Puppys. But if I were certain that a 'deb' wasn't needed, how would I 'strip' them from the build?

-=-=-=-=-=-
* Bye the way, I could not run gnewpet under Fossapup64-9.6. It is NOT a 'user-merge' problem. I looked. My next guess is that the current bash dialect is sufficiently different than that used by jpeps in Jan 2012 when he last updated the application. Or it could be that gnewpet doesn't work when installed pets are cataloged in /var and symlinked back. At any rate, someone with actual coding skills should look into this. gnewpet is really a very useful tool.

[mikeslr]

I just found 666philb's instructions here: http://oldforum.puppylinux.com/viewtopi ... 6#p1022476:
"...
4. in that folder is the DISTRO_PKG_SPECS file. this is the recipe for all the packages in that particular puppy. open it in geany and choose what packages to remove by simply changing yes| to no| at the start of the line. lots of packages are obvious like abiword & deadbeef.. so just start by saying no to the recognisable ones..."

That seems to suggest two things. PLEASE CORRECT ME IF I'M WRONG'. DISTRO_PKG_SPECS is a file which will be reference during the entire process and, accordingly by the 2createpackages script. As items on the list take the format such as

yes|jwmconfig3||exe
and
yes|syslinux_xenial||exe,dev,doc,nls| #must use pet syslinux pkg.

'suffixes' such as that of the jwmconfig3 pet (jwmconfig3-151025) are ignored. Changing 'yes' to 'no' will remove an application from woof's 'ToDo' list during the entire process

Question: would editing the listing for syslinux above to
yes|syslinux_xenial||exe,nls| #must use pet syslinux pkg
--note dev and doc have been deleted-- be the way to not have its dev and doc files included in the build?

And lastly, would adding a listing such as the following

yes|MY-APPLICATION||exe

--with an appropriate MY-APPLICATION.pet located in local-repositories/x86_64/pet-packages-- result in MY-APPLICATION being included in the build (assuming the MY-APPLICATION.pet was properly structured?)

Thanks in advance.

[mikeslr]

bump

"... 2createpackages generated an error message that read:

"ERROR: 'jwmconfig3' package does not exist.
You will need to find a matching package and place in packages-pet,
or packages-deb-xenial as appropriate.
Do it, then rerun this script and choose to build jwmconfig3.

ERROR: 'syslinux_xenial' package does not exist.
You will need to find a matching package and place in packages-pet,
or packages-deb-xenial as appropriate.
Do it, then rerun this script and choose to build syslinux_xenial."
...
But does the 2createpackages script 'index' pets it finds there and then use that index; or was there some earlier part of the scripts which created such 'index'; or something else?
..."

Just placing pets in local-repositories/x86_64/pet-packages is apparently not sufficient. What else has to be done to enable woof to make use of them?

[peebee]

You need an entry for the pet in one of the repo database files - e.g. like Packages-puppy-noarch-official

The entry is just the line from the pet.specs file

You can have a repo database just for your build but you will need to add it to DISTRO_PET_REPOS - e.g. I have Packages-puppy-s15pup-extra

You can add the entry to one of the existing databases for testing purposes but note that the database will be redownloaded if you do a 0setup

[mikeslr]

Thank you, peebee.

I'll try to digest your instructions while examining the folders, sub-folders and files running woof creates. But first I have to digest the too much food I ate and wine I imbibed yesterday.

[dimkr]

examining the folders, sub-folders and files running woof creates

https://github.com/puppylinux-woof-CE/w ... -structure

[mikeslr]

Thanks, dimkr. Now why didn't I think of that? "When in doubt, read the instructions."