sc0ttman wrote:s243a wrote:sc0ttman wrote:
Of course, I first and foremost intend to get Pkg working in official Puppies ...
Your devuan acsii version is an 'edge case', for now...
Not sure if the following is an "edge case issue" or a woof-CE issue
If you are not running a standard Puppy (which you are not), then for Pkg it's 100%
an "edge case" - because Pkg is designed (mainly) for standard Puppy Linux releases.
I have no idea if your custom OS (half Puppy, half something else) has everything setup
correctly... I don't even know if it was built with Woof... Hence,
your OS is the "edge-case"
as far as Pkg development is concerned.
I started a thread on it:
tiny_puduan_ascii-PreAlpha11 (made via a woof-next fork)
It's not built via woof but it uses puppy init scripts and most of the rootfs-skeleton.
Code: Select all
Anyway, I tried to work out if it's a Pkg issue....
thankyou
I know that the package manager...
Which one?? Pkg? PPM? PPM 3.0?
..writes to the actual save layer but in my case
the save layer is:
.....
Edit: After further examination this might be an issue with mistfire's package manager.
I search for pup_ro1 returns nothing that seems relevant in the gitlab branch for pkg.
Then I think you should probably post it at the PPM 3.0 thread, or even better work out if it's
actually a Woof-CE issue before posting at either... I guess..?
I did notice though that pup_r01 is used in sfs_loadr.
Code: Select all
6) SAVE_LAYER='/pup_rw'; PUP_HOME='/pup_rw'; PUPSAVE='sda1,ext2,/';;
12) SAVE_LAYER='/pup_rw'; PUP_HOME='/mnt/dev_save';;
13) SAVE_LAYER='/pup_ro1'; PUP_HOME='/mnt/dev_save';;
77) SAVE_LAYER='/pup_ro1'; PUP_HOME=''; PUPSAVE='sr0,iso9660,/2011-01-27-20-26';;
/usr/sbin/sfs_loadr#L1697
....
I think that PUP_HOME should either be /mnt/home or /initrd/mnt/dev_save/
**note that /mnt/home is a symlink pointing to /initrd/mnt/dev_save
Yep.. That is what I have on my system (Stretch RC something..) and most Pups I'd imagine..
But it depends on the install method/type... Sorry but I can't reproduce those issues..
...More generally ...
I think maybe you're posting "too soon", if you don't mind me saying so...
The first long series of posts you posted to the Pkg thread turned out to be your /etc/DISTRO_SPECS
not being setup correctly, which wouldn't have happened in a standard Puppy...
In my opinion pkg should in theory still work with an incorrectly configured /etc/DISTRO_SPECS, because there is enough information in /root/.pkg/sources to find the DB file online for the package. For instance in my setup I have the following (for the 1st line):
Code: Select all
ascii-main|deb|Packages-devuan-ascii-main|http://deb.devuan.org/merged/||||noarch common ascii ascii-backports ascii-contrib ascii-multimedia ascii-non-free stretch-main stretch-backports stretch-contrib stretch-multimedia dpup upup
The path to the DB file is:
Code: Select all
http://deb.devuan.org/merged/dists/ascii/main/binary-i386/Packages.gz
http://deb.devuan.org/merged/dists/ascii/main/binary-i386/Packages.xz
the only part of these paths not in souces is the part that says "dist" and the part that says "binary-i386". In lieu of this info pkg could try testing alternatives and could ask the user if they want to over-ride the settings in distro specs.
In my case initially pkg would fail because I originally had TARGET_ARCH='x86' when it should be TARGET_ARCH='i386' but if pkg was able to infer the architecture (e.g. looking at the elf type of libc) then it would know to try i386 in the path.
**maybe a file could be added which specifies the "ARCH" format for each repo.
Note that at the moment some of this is outside the scope of "pkg" because the repo update is done by files which are currently part of puppies package manager.
Code: Select all
And sorry, but I also don't want this thread mixed up with mistfires PPM 3.0 (which literally runs
[i]against[/i] to the goals of this project).. Pkg is not designed to support PPM 3.0 (unless it becomes
Puppys official/main PPM).. even then, Pkg aims to become independent of any PPM..
...
I think you should probably test Pkg on a standard Puppy to compare to your OS before posting any
issues here in order to make sure the issues are with Pkg and not your custom OS..
Currently pkg still depends on some files from the puppy package manager. These files could be from the current puppy package manager, mistfires version or the latest woof-CE code. Since pkg aims to be independent of the ppm, may I suggest having a variable that points to the directory where the needed ppm files are. One could make this independent of puppies ppm by simply pointing to a different directory than the default puppy ppm.
**although it might also want to use a different directory for temporary files.
Anyway, regarding testing on a standard puppy; it seems to be the case that there are a lot of woof-CE changes related to puppies package manager. Some of these are related to improvements by mistfire. If pkg aims to be compatible with the lastest woof-CE code then the code is too unstable at this point. If pkg aims to use legacy puppy package manager code then it should include these files as part of the project and put them in a separate directory than the default puppy package manager.
Anyway, the reason that mistfire's code interested me was that in her x-slacko slim release the ppm appeared to be able to downloaded packages from many different repos.
**In theory pkg should also be able to do this based on the soures file.
For this to work, I think that the dependencies on DISTRO_SPECS should be removed, in mistfire's ppm 3.0 thread, it appears to me that there are still some dependencies on DISTRO_SPECS related to updating the package data base files. Therefore, I'm not sure if x-slacko slim properly updates databases which aren't part of the compatible distro.