rufwoof wrote:Hi wiak. When I very cursory glanced over some of the code my mental image was that it pulls down list(s) of what's in the corresponding puppy, validates the md5 checksum of those lists and then wades through those lists ... if the corresponding file already exists in the local repository then doesn't download, otherwise it is downloaded ... without md5 checking each. My fluency in reading 'script' however is a lot lower than yours, so I'm likely wrong.
If a package/lib is changed then generally it tends to have a new filename (version) ... often a dash version for instance in Xenial there's a perl_5.22.1-9_amd64.deb suggesting to me that version 5.22.1 of that has been updated/changed 9 times.
What I don't know is how the main filelist files are maintained. I'm guessing that if for instance Ubuntu/Debian release a perl_5.22.1-10 then there could be a automated script that perhaps runs nightly to change the main list within woof-CE so that's reflected through? I suspect perhaps not however and that it takes a developer to select what is in the Puppy so as to keep it more stable (unchanging), so ... for instance, a later perl_5.22.1-10 rolled out by Ubuntu might not be updated in woof unless specifically selected by a developer as the version in woof for puppy xyz. I'm hoping for the former, but suspecting the latter.
Actually, rufwoof, my 'understanding' of the md5 checking of the package lists is much the same as you write above (the md5 checks are on the pkg lists). And my 'worries' about these package lists (and lack of knowledge about them) is currently identical to yours. This is part of the reason I'm taking a rest to get some energy back cos need to read more of these extremely long scripts to see if there is any clue about that. Would be a real pity if these package lists do need to be manually updated every so often on woof-CE itself, but I also wonder how it can be getting done otherwise... (my hope is that woof-CE scripts actually download package lists somehow from up-stream Debian/Ubuntu etc, though I don't know if that info is available from there - maybe you know?) Anyway, I guess 0setup, 1download, _00func, and support/findpkgs scripts (along with the stuff they source) may contain the answers to these questions... Time will tell. Still fun to play around with though (and exercise for the brain).
EDIT: most useful and time-saving would be if jlst or 01micko will tell us or if we ask them of course. Will do so if I can't work it out myself soon, or you don't either.
EDIT2: This is one of the advantages in debootstrap in Debian of course. Potentially big team of developers and since it is from Debian everything being kept up to date. Makes scripting Debian-based systems relatively simple really.
EDIT3: I suppose if you have an actual Debian Stretch system you can apt-get update packages and compare with what Puppy woof-CE provides and see if any and all packages are up-to-date or not... Like you, I doubt it. If not, then that is main thing that Puppy developers/woof-CE-stewards need to work on. Or alternatively, forget Debian/Slackware etc compatibility and go back to trying to build smaller Puppy using its own repository via woof-CE (like tiny core and Slitaz do) - yes, disadvantage then of lots of build work and small repository, but maybe advantage of smaller size possibility? I know hardware resources tend to be large now anyway, so small distribution size not often so important, but sometimes nice anyway (and certainly on older laptops/machines). Maybe should see if possible to woof from tiny core or Slitaz repos actually... but again package lists need to be kept somehow up to date.
EDIT4: Could be this: support/debdb2pupdb but this is a compiled binary, so need to find/read the original source code. Actually, I'm becoming hopeful that DISTRO-PKGS-SPECS-<distro-version> information is indeed downloaded form upstream debian (or whatever main distro is) and for example, for slackware, related to this file: DISTRO_COMPAT_REPOS-slackware-14.
For example, in there (along with other possible repos) we have:
Code: Select all
PKG_DOCS_DISTRO_COMPAT="
z|http://ftp.nluug.nl/pub/os/Linux/distr/salix/${DBIN_ARCH}/slackware-${DISTRO_COMPAT_VERSION}/PACKAGES.TXT
The above resolves to the package database list file:
http://ftp.nluug.nl/pub/os/Linux/distr/ ... CKAGES.TXT
If you go to that url you should see the package details and I think that is likely downloaded and processed by 0setup and code called from that.
If you build a Debian Stretch Puppy instead and look in DISTRO_COMPAT_REPOS... I expect you'll find the url to the similar package database file for Debian Stretch which 0setup will automatically download and process when building Pup based on that distribution etc...
In other words, I'm becoming pretty sure 0setup script is automatically updating the distro package lists, in which case auto-updates should work fine. [/b]Maybe I'm just an optimist (!) and nothing to do with makepup development really, so I'll just move on with that for now.
The following and more in 0setup:
Code: Select all
#download docs on compatible-distro pkgs...
function download_compat_pkg_dbs() { etc...
...
if pkg_db_confirm_download ; then
DLFILE="`basename $PKGLISTURI`"
[ -f $DLFILE ] && mv -f $DLFILE /tmp/${DLFILE}-backup1 #v431 otherwise wget creates a new file ${DLFILE}.1
[ "$DBmethod" = "true" ] && rxvt -name pet -bg orange -geometry 80x10 -e wget $PKGLISTURI || wget $PKGLISTURI
etc...
wiak