Tiny Core Linux

dCore Import Debian Packages to Mountable SCE extensions => dCore X86 => Topic started by: nitram on December 26, 2015, 12:02:51 PM

Title: jsce-remove -k option query
Post by: nitram on December 26, 2015, 12:02:51 PM
Working on updated --help dialogue for sce-remove. One of the options is  sce-remove -k  , related to keeplist, referenced to /etc/sysconfig/sceconfig. Current usage info "will not remove .lst and .dep files, can be used with SCE name, useful for future imports". Running sce-remove -k gives illegal option, so i can only ASSume this is for internal script use only based on user's sceconfig file preference. Please simply confirm so i can accurately update the help file. Thanks.
Title: Re: jsce-remove -k option query
Post by: Jason W on December 26, 2015, 12:26:55 PM
The -k option is valid for keeping those files.  I will look into why it is not working.
Title: Re: jsce-remove -k option query
Post by: nitram on December 26, 2015, 04:47:43 PM
Thanks for looking into it. Maybe i'm just not using it properly. but tried both:
Code: [Select]
tc@box:~$ sce-remove -k bsdgames-nonfree
Illegal option -k
tc@box:~$ sce-remove -k
Illegal option -k

Title: Re: jsce-remove -k option query
Post by: Jason W on December 28, 2015, 03:43:11 PM
Should be fixed in the latest RC.
Title: Re: jsce-remove -k option query
Post by: nitram on December 31, 2015, 06:49:29 PM
Running  sce-remove -k bsdgames-nonfree  no longer gives illegal operation error and successfully removed the extension. Unless i misunderstand it's function, however, i can't fully test as none of my /tce/sce extensions have or require .lst or .dep files. Could someone please test remove an extension that has a .lst or .dep file to confirm everything is good after the latest dCore update 2015.12.31.11.11. Thanks.
Code: [Select]
tc@box:/mnt/sdb4/tce/sce$ ll
total 251M
-rw-rw-r-- 1 tc staff 948K Dec 31 15:33 Xprogs.sce
-rw-rw-r-- 1 tc staff   45 Dec 31 15:33 Xprogs.sce.md5.txt
-rw-rw-r-- 1 tc staff 4.9M Dec 30 04:07 beaver.sce
-rw-rw-r-- 1 tc staff   45 Dec 30 04:07 beaver.sce.md5.txt
-rw-rw-r-- 1 tc staff 4.8M Dec 31 15:33 bsdgames-nonfree.sce
-rw-rw-r-- 1 tc staff   55 Dec 31 15:33 bsdgames-nonfree.sce.md5.txt
-rw-rw-r-- 1 tc staff  17M Dec 29 21:32 conky.sce
-rw-rw-r-- 1 tc staff   44 Dec 29 21:32 conky.sce.md5.txt
-rw-rw-r-- 1 tc staff  36M Dec 29 21:32 dillo.sce
-rw-rw-r-- 1 tc staff   44 Dec 29 21:32 dillo.sce.md5.txt
-rw-rw-r-- 1 tc staff 4.9M Dec 29 21:32 emelfm.sce
-rw-rw-r-- 1 tc staff   45 Dec 29 21:32 emelfm.sce.md5.txt
-rw-rw-r-- 1 tc staff  19M Dec 29 21:32 fluxbox.sce
-rw-rw-r-- 1 tc staff   46 Dec 29 21:32 fluxbox.sce.md5.txt
-rw-rw-r-- 1 tc staff 1.3M Dec 29 21:32 graphics-3.16.6-tinycore.sce
-rw-rw-r-- 1 tc staff   63 Dec 29 21:32 graphics-3.16.6-tinycore.sce.md5.txt
-rw-rw-r-- 1 tc staff  97M Dec 29 21:32 iceweasel.sce
-rw-rw-r-- 1 tc staff   48 Dec 29 21:32 iceweasel.sce.md5.txt
drwxrwxr-x 2 tc staff 1.0K Dec 31 15:45 update/
-rw-rw-r-- 1 tc staff  66M Dec 31 15:38 xorg-intel.sce
-rw-rw-r-- 1 tc staff   49 Dec 31 15:38 xorg-intel.sce.md5.txt
Title: Re: jsce-remove -k option query
Post by: nitram on January 02, 2016, 10:52:19 AM
Ok, retested. Did  sce-import -l terminals  , which included lxterminal and terminator. Built a nice SCE, appropriately enough called terminals.sce, which included a terminals.sce.lst file. Only know how to create .dep files hacky, manually created terminals.sce.dep, with one entry bsdgames-nonfree.sce. Ran  sce-remove -k terminals  . The terminals.sce was removed upon reboot, the terminals.sce.lst and terminals.sce.dep were left. AFAIK, the -k option is, therefore, working correctly. If so please mark solved.

Note: The bsdgames-nonfree.sce did NOT get removed. I thought it might/should? Maybe i didn't create the terminals.sce.dep file properly or  sce-remove  is not designed to remove deps?
Title: Re: jsce-remove -k option query
Post by: Jason W on January 02, 2016, 05:42:47 PM
Thanks, I will look into it.

If the tool requires .dep or .lst files, that is a bug.  Will correct.
Title: Re: sce-remove -k option query
Post by: nitram on January 23, 2016, 01:24:27 AM
Re-created terminals.sce from list file with a dependency on nano.sce. Ran  sce-remove -k terminals  and /tmp/.sceremove file contains only 'terminals', not nano. Didn't reboot but does not appear nano got flagged for removal.
Title: Re: jsce-remove -k option query
Post by: Jason W on January 23, 2016, 11:47:57 AM
Was the .dep file manually created? 
Title: Re: sce-remove -k option query
Post by: nitram on January 23, 2016, 12:45:00 PM
Yes, manual.
Code: [Select]
tc@box:/mnt/sdb4/tce/sce$ ll | grep terminals
-rw-rw-r-- 1 tc   staff  66M Jan 22 23:16 terminals.sce
-rw-rw-r-- 1 tc   staff   33 Jan 22 23:16 terminals.sce.debinx
-rw-rw-r-- 1 tc   staff    9 Jan 22 23:18 terminals.sce.dep
-rw-rw-r-- 1 tc   staff   22 Jan 22 23:16 terminals.sce.lst
-rw-rw-r-- 1 tc   staff   48 Jan 22 23:16 terminals.sce.md5.txt

Code: [Select]
tc@box:/mnt/sdb4/tce/sce$ cat terminals.sce.dep
nano.sce
Title: Re: jsce-remove -k option query
Post by: Jason W on January 23, 2016, 01:08:02 PM
Ok, manually created .dep files can cause issues, and they don't support the .sce suffix in the entries.  The SCE dependency is a complex and when created by "sce-import  -d" there is no duplication between a .dep file entry and the main SCE.  The goal is to have no manual involvement in the SCE directory.  The entries in the .dep files druing import also place information in the /usr/local/sce/$scename directory.

But that being said, in regards to sce-remove it should still work with manually created entries that have no .sce suffix in them. 
Title: Re: sce-remove -k option query
Post by: nitram on January 23, 2016, 02:06:10 PM
Thanks for the explanation. My ignorance, didn't think the  -ld  options could be used in combination, so re-running with only the  -d  option afterwards wanted to re-import the entire terminals.sce. Actually if a same named lst file is in the working directory, noticed that the -l option isn't even required, just finds the list and asks -nice. Anyway ran  sce-import -ld terminals  , selected install terminals from list file, selected nano as dependency (automated method), which created a /usr/local/sce/terminals/terminals.dep file containing 'nano'.

Still removing terminals does not flag nano for removal, confirmed by looking at /tmp/.removesce:
Code: [Select]
tc@box:~$ sce-remove -k terminals
 
terminals
 
The above SCE(s) will be removed upon shutdown or reboot.

Completed simpler test not involving a list file, ran  sce-import -d lxterminal  and selected bsdgames-nonfree as dependency. Then running  sce-remove lxterminal  indicates only lxterminal will be removed,  not it's dependency bsdgames-nonfree.

The title of this thread is no longer accurate, it appears to be a dependency removal issue, regardless of using a list file or the -k (keep) option.

Is it because i'm not rebooting between tests (i would expect the dependency nano or bsdgames-nonfree to be in /tmp/.removesce)?
Title: Re: jsce-remove -k option query
Post by: Jason W on January 23, 2016, 02:13:41 PM
Ok, I see what is happening.  terminals.sce has nano as an entry in the terminals.sce.dep file.  If removing terminals, there is no reason to remove nano.sce from the SCE directory. 

But with those sces in that arrangement, if you did "sce-remove nano" then it would also remove terminals.sce since terminals depends on nano and packages that nano.sce contains, and therefore would be broken if nano.sce was removed. 

I'm not sure I want to have every sce listed in a dep file removed since those sces are freestanding or still have their needed sces that are listed as deps and are not broken by sces being removed with sce-remove. 
Title: Re: jsce-remove -k option query
Post by: nitram on January 23, 2016, 02:41:33 PM
Re-ran sce-remove from the simpler lxterminal example but removed bsdgames-nonfree instead of lxterminal, then got:
Code: [Select]
tc@box:/mnt/sdb4/tce/sce$ sce-remove bsdgames-nonfree
 
bsdgames-nonfree
lxterminal
 
The above SCE(s) will be removed upon shutdown or reboot.

When i created lxterminal, bsdgames-nonfree was selected as a dependency. Shouldn't removing the primary SCE remove the dependency, not removing the dependency remove the parent SCE? IIRC in TC 6, attempting to remove the dependency (bsdgames for example), Apps wouldn't allow, indicating lxterminal depends on bsdgames.

When sce-import -d lxterminal asks 'Choose the sce you want use as a dependency of lxterminal..', isn't it asking 'choose the SCE you want lxterminal to depend on'? Maybe the issue is that bsdgames would then need to be reimported with the dependency flag. Forgive me if confused...

I think i understood what you were last explaining, it would get messy. As SCEs are self contained and users can create list files, maybe there's not much need for a dependency option. Personally i probably wouldn't use it, just enjoy testing and learning the system so it came up. If you think everything's working correctly then no problem, sorry for the trouble :)
Title: Re: jsce-remove -k option query
Post by: Jason W on January 23, 2016, 06:27:30 PM
If I choose an sce as a dependency, then that dependency chosen does not need the sce that using it as a dep.  But the sce that is using another as a dep needs those sces to make it complete.  If a package needed by the main sce exists in an sce chosen as a dep, then that package will not be in the main sce.  This is to allow much smaller sces when using the dependency option. 

There is no reason to remove sces that are chosen as a dep, if we want to do so then we can choose them from the menu.    And if you removed bsdgames-nonfree and not lxterminal, then lxterminal would have to be re-imported to be complete, not the other way around.

What this does is allow you to remove dependencies and not leave the system broken.  To do that, anything that depends on sces chosen for removal are also removed.    If we made an option where items in the .sce.dep file are removed, then all that is using them as deps would have to be removed too.  Could result in a long list, unless an option was there to not allow for removal those sces that have others depending on them, but then it would be pointless as it wouldn't allow much to be removed.
Title: Re: jsce-remove -k option query
Post by: Jason W on January 23, 2016, 06:40:10 PM
Here is a case in point, I have imported aisleriot with no deps so no dep file.  I import file with the -d option and in choose aisleriot as a dependency, so file.sce.dep file includes the entry aisleriot.  I import emelfm with the -d option and choose file as it's dependency sce, so emelfm.sce.dep includes file.

Now I go to sce-remove.   If I choose only aisleriot, the below sces will be removed:

aisleriot
file
emelfm

If I choose file, the below will be removed:

file
emelfm

If I choose emelfm, only emelfm will be removed.  Without being re-imported, file needs aisleriot.sce and emelfm.sce needs both file.sce and aisleriot.sce to be complete. 
Title: Re: jsce-remove -k option query
Post by: nitram on January 23, 2016, 11:45:46 PM
Thanks for the explanation and especially the example, will try to work more examples into the --help files to help others. The concepts aren't that difficult even for me to eventually understand, but an example goes a long way.

Actually what also helped a lot, when running  sce-import -d lxterminal  , for example, the first message is 'choose the SCE you want to use as a dependency of lxterminal'. That kind of threw me, BUT later after selecting dependency(s), the screen briefly flashes this before starting the import and scrolling off screen: 'the below (selected) SCEs in your SCE directory will be used as to provide dependencies for lxterminal'. For my brain 'to provide dependencies FOR lxterminal' were keywords, then it made sense.

Just completed a test, now i see the magic of incorporating a dependency, imported stand alone:
terminator 65mb
lxterminal 35mb

Running sce-import -d lxterminal and selecting 'terminator' as dependency, now lxterminal is only 192kb !

Also loading lxterminal now also obviously loads terminator, two terminals to choose from :)

Thanks again, everything works well.