dCore Import Debian Packages to Mountable SCE extensions > dCore X86
few service questions
dicorer:
ub-dCore-utopic.gz
/bin/lsmmod -> ../bin/busybox
dicorer:
debGetDeps:
--- Code: ---elif grep "^$PKG:" /tmp/PKGPREBUILTDEP > /dev/null 2>&1; then
DEPLIST="$DEPLIST `grep "^$PKG:" /tmp/PKGPREBUILTDEP | cut -f2 -d:`"
else
--- End code ---
DEPLIST is appended with its previous value?
if previous DEPLIST value is dirty, dont we risk to load wrong PKGs?
also
2 same greps are done here, since getDeps is recursive, might be better optimized for speed?
e.g. load the first grep result in a variable, and use it down in replace of the second grep?
=================
sce-import , the -l option.
if given a wrong list file name, it drops down the cp usage... might appropriate to trap this exception?
Jason W:
To ensure that DEPLIST is not dirty at the invokation of debGetDeps, I reckon I could unset it before the function, but it is working now and I have not seen any cases of corruption.
Thanks for your insight. But I spent many, many afternoons in trial, error, and testing polishing and tweaking the dependency gathering routine that was the fastest yet has to be accurate. It is documented in the threads here.
To get the dependency list of vlc takes 5.01 seconds to gather 135 package names. That is with parsing PKGPREBUILTDEP, the extra debinx files, and the main one in that order until found. I am satisfied with the current speed and do not wish to break things in an effort to further streamline.
But if you have a code suggestion, I will listen since we are not messing with the dep gathering from the debinx files but just from the prebuilt list.
dicorer:
I remember this issue I reported earlier here:
http://forum.tinycorelinux.net/index.php/topic,18263.msg111030.html#msg111030
"coreutils" and "crda" were imported erroneously, it might be that?
I also agree unsetting the value before could solve the case, anyway I didn't try.
About speed, I do all under virtual machine, that's why I can feel the weight of every instruction there.
I didn't perform any non-functional test of course, because in fact I thought you must have done that already, so just pointed out some options I got in mind.
Clearly, if you already did all tests cases possible, small word, no point in checking that again.
As I said, my efforts were in fact to be focused in disabling (not improving) the prebuilt packs and bed2sce custom scripts access.
I successfully accomplish that, which gave me much higher granularity of options when selecting packages.
I'm happy that my test results are confirming my expectations.
Afaik, both rebuilt packs and deb2sce scripts can be disabled safety, in the case the application works well already without.
In case it doesn't work, it seemed to me, its always matter of a small missing detail, and a look to the deb2sce script helped in finding that detail.
I had the feeling that some scripts and pack actually in use, contain outdated procedures when applied to ubuntu pack, but I might be wrong.
Anyway, something to really keep in mind, came out of my tests: dCore busybox is bugged ;)
And unfortunately the few versions at ubuntu repo, even more bugged! ;D
Apart depmod problem, the cp likes to messup, when dealing with symlink, meaning links get overwritten and targets get lost.
That happen mostly when loading in different sce, packages belonging to the same functionality, e.g. libs in one sce, the dev in another sce... but not only.
Also that, I didn't investigate further, clearly I'm not going to fix busybox bugs, simply I went by workarounds: pay attention to where put similar debs and don't duplicate them in other sce.
Then, I might have other technical matters to report, but I don't know if you are interested.
Jason W:
coreutils does not get imported erroneously, it replaces the busybox commands of the same name, it is set up like that by design and has been by Tinycore since the beginning.
I have not seen an issue with DEPLIST being corrupt, if you find an instance please report the specifics.
To grep PKGPREBUILTDEP for the phrase "file", it takes about 2 seconds to grep it 1000 times. About 8 seconds when double grepping, and about 5 seconds when exporting the first grep to a variable and then testing that variable to be not null. So a little time can be saved, but not much. Grepping that file once results in a 0.00 time usage.
There could be some use for disabling the prebuilt section, but I have never heard that requested. And there is no reason or use for disabling the startup scripts as they exist for one thing - to make the package work as expected. And the startup scripts are designed to work across Debian and Ubuntu, and across package versions. Portability is a main goal of dCore.
As for buggy busybox or Debian/Ubuntu builds, the place to report them would be those upstream projects. But for Debian or Ubuntu, first install that system, test the package, and then report. If a package works on Debian but not dCore, then it is a dCore issue and we can deal with it here. Specific commands, details, and results are most helpful.
I am interested in issues or bug reports, but much of what you are reporting is dealing with your own custom use of dCore.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version