dCore Import Debian Packages to Mountable SCE extensions > dCore X86

sce-update, possible quick check feature

<< < (4/10) > >>

Jason W:
Ok, thanks for testing.  Here is what I see.  Debinx needs to be run anyway to produce the /tmp/debinx but without producing a new OLDDEBINX, I have not rebooted in testing this so I overlooked it.  Will be added.

Md5sum is checked to see if the NEWDEBINX and OLDDEBINX are different in any way, and if so triggering a normal sce-update.  But a diff could be offered for those who would like to view as an expert option as to whether to proceed with sce-update.  Today dCore-wily had libvirt-bin and related packages added to the debinx that were not there an hour ago but a newly introduced package and not relevant to my install.

Viewing your diff, the + entries appear to be what is changed in the NEWDEBINX.  Correct me if I am wrong.

If the OLDDEBINX and NEWDEBINX are different at all per md5sum, then checking an individual SCE or all or a menu selected list is still just like before.  I am for the diff viewing and an informed decision for expert users, but let's first make this a stable cut after some more testing, I need to upload to a stable cut to release and then we can further add features.

Jason W:
Fixed needed detGetEnv on first run, please check.

nitram:
Yes as per the diff output above:
--- OLDDEBINX
+++ NEWDEBINX

I don't understand how this DEBINX diff works, however. The diff from above listed Fluxbox which i use, why not updated? Already deleted, next time will open in vi, go to line #323546 or whatever and take a closer look. Maybe because Fluxbox is dCore pre-built, overrides Debian repository. But then incorrectly, i would feel obligated to run  sce-update fluxbox.

Agree with getting stable first, hence code words 'sce-update has been under revision, so just food for thought or maybe future feature' and 'Just thinking outloud'. Certainly don't intend to disrupt your life with a new RC within hours, just something to think about while the topic is fresh. The work you do is incredible. This stuff is just nice to have...and save unnecessary CPU cycles. Don't consider myself expert, still learning, but i think most dCore users would appreciate this feature.

Just read your note, will re-test later tonight. Thanks.

Jason W:
Ok, I see the issue with prebuilt versus Debian as far as needing updates.  This diff or md5sum check of catted debinx, prebuilt, files can only determine if something was changed, not what and where as in what repo. Is only good to determine if nothing at all was changed, then no need to run regular sce-update.  Otherwise, sce-update as usual. 

We can determine if this is really useful as if something is updated in Debian/Ubuntu but the prebuilt supercedes it, then an update is really not needed but is indicated by the change in Debian/Ubuntu.   

It's all good, because certainly nothing lost by this addition and can save a full "sce-update -a" when no changes in debinx or perbuilt have been made, but when changes in the debinx files, it is not clear whether really needed.   

With existing routines using the OLD and NEW debinx diff info, we can tell what repo packages available for update come from, and even get which SCEs are affected.  And much quicker than the current sce-update routine does as it would be grepping one word per package change rather than doing a full md5sum checking of each or every SCE.  Lets stay with this thought.

Jason W:
Oh, and when I see new ideas and concepts I tend to go with them when they seem they may make things more efficient or useful.  Sometimes they don't work, other times they do, time and testing will tell in the end.  Everyone keep the ideas coming.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version