General TC > Remasters / Remixes - Unofficial
corepkg - a new core package and updates manager
martin:
(comment removed, but saved offline. can't be bothered venturing into politics.)
I'll use this space to demonstrate instructions instead.
Sample commands tested, working and ready:
* corepkg -f - fetch package database
* corepkg fetch - same as above
* corepkg -u - check if updates are available, but do not download them.
* corepkg -uf - same as above, but download them.
* corepkg update - same as -uf above
* corepkg -df package[.tcz] - similar functionality to (but does not use) "tce-load -w [package]", fetches an extension and all dependencies (recursive) for later installing, storage and transporting. This is considered the "offline downloading" part.
* corepkg -i package[.tcz] - wrapper to "tce-load -wi"
* corepkg install - shortcut for above
* corepkg search keyword - searches entire database for references to [keyword]. This will soon include all files within packages as well.
* Server side compilation only: corepkg -g - Re-freshes the package database pkg.db.
Features in progress:
* Display estimated download size for packages to be updated.
* Keyword search to the include file list.
Related Summary:
My primary and first motivation for making corepkg at the start was how long it took tce-update to work. Then a few days after I started (it was 80% complete at the time), I saw a member here post about how slow it took tce-update to work for them. A few days later (just before the convention), I saw Robert mention that something was being worked on for 4.3 to help address this. CorePkg was complete and working by then (I sent a PM to Robert at this time introducing my software and what it did). It was a little after that that I announced CorePkg publicly.
Keeping that in mind, corepkg's second primary motivation was simply speed. If the official tools can detect potential updates quicker and perform keyword searches quicker than corepkg, I'll re-consider whether corepkg needs to exist. If corepkg is faster at both than the current tools and those in testing for 4.3, I'll keep working on it. CorePkg will never be faster at fetching extensions and/or installing them, as it uses the very same methods as tce-load does (wget to get the software, tce-load to install them).
The timings I made for corepkg are on the previous page. I can't time appbrowser doing a keyword search because I don't think it accepts one on the command line.
roberts:
--- Quote ---My primary and first motivation for making corepkg at the start was how long it took tce-update to work. Then a few days after I started (it was 80% complete at the time), I saw a member here post about how slow it took tce-update to work for them. A few days later (just before the convention), I saw Robert mention that something was being worked on for 4.3 to help address this. CorePkg was complete and working by then (I sent a PM to Robert at this time introducing my software and what it did). It was a little after that that I announced CorePkg publicly.
--- End quote ---
Stop with the suppositions and taunting.
Facts using an md5 database was internally suggested to me on Jan 11.
Your first PM to me is dated Jan 16. However the result is A 4MB database versus 96k. A intergated GUI versus command line. Integrated code versus an extension requiring connection to an offsite database thay can never be as current as the official site.
I
martin:
--- Quote from: roberts on February 05, 2012, 10:38:58 PM ---
--- Quote ---My primary and first motivation for making corepkg at the start was how long it took tce-update to work. Then a few days after I started (it was 80% complete at the time), I saw a member here post about how slow it took tce-update to work for them. A few days later (just before the convention), I saw Robert mention that something was being worked on for 4.3 to help address this. CorePkg was complete and working by then (I sent a PM to Robert at this time introducing my software and what it did). It was a little after that that I announced CorePkg publicly.
--- End quote ---
Stop with the suppositions and taunting.
Facts using an md5 database was internally suggested to me on Jan 11.
Your first PM to me is dated Jan 16. However the result is A 4MB database versus 96k. A intergated GUI versus command line. Integrated code versus an extension requiring connection to an offsite database thay can never be as current as the official site.
I
--- End quote ---
wrong thread. and I didn't know on the 16th that another one was being worked on, so I had no idea. besides, I thought this was already resolved? I mean, it's not like it's going to make the work you have put in your version redundant, so it's not like there is a threat or anything.
martin:
Let it be known that I have privately made another offer of reconcilliation towards Robert and to make amends for whatever it was I did to offend and upset him. I really, REALLY do not know what it was! I'm not kidding, being sarcastic or provocative at all.
Just trying to amicably fix this. My offer is on the table.
edit: come on Robert, please don't let a potentially great partnership (we are all partners in helping make TinyCore Linux awesome and useful for all computer uses) and possible friendship turn sour.
martin:
One more. Whether you're annoyed at the seeming duplication of effort or what, I don't know because so far you wont tell me.
So, another gesture to prove I only want to help, contribute and what not. If not the updates and keyword search facilities, tell me then, what parts you DO need or want assistance with in the base. I've contributed several extensions of programs I use a lot so I can enjoy them under TCL. Tell me then, where would you like the extra man power within the base or another part of the project and I'll get to work.
No kidding, if this is the only way I can prove to you beyond all doubt I have only good intent here, so be it.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version