dCore Import Debian Packages to Mountable SCE extensions > dCore X86

importsce "add-on".sces based on "base".sces

<< < (9/12) > >>

Jason W:
Checkmissingdebs is really a way to protect the user from himself.  Say he imports base.sce from a package list, then uses it as a dependency for firefox.  Then later he re-imports base with a shorter file list than before, leaving out libgtk2.0-0 or any package that firefox is dependent upon.  On rebooting, he sees firefox does not work.

He can run "checkmissingdebs firefox" and it will tell him that at the time firefox was imported using base as a dep, base contained libgtk2.0-0 but now it does not.  He can then re-import firefox and all is well.

Any missing dependencies from re-importing dependency packages that result in a broken app that depends on it can be identified.  Say firefox depended on desktop.sce which depends on base.sce, a missing package in base or desktop or even firefox will show up when checking firefox.

I redid checkmissingdebs to have more clear messages.  /tmp/.debinstalled is the list of packages (debs and prebuilt, not the sce's) that are installed in the system.  And that is the file that is used by checkmissingdebs.  To test functionality without re-importing sce's that are used as dependencies just delete entries from that list, emulating their not being installed in the system. 

I will look into the echoing of missing /tmp files, I thought I covered the bases but something is supposed to be redirecting to null output that is not.

Jason W:
Importupdatecheck updated to reflect current changes.

yoshi314:
that might be a stupid question to ask, but is there a package that will provide user with basic system?

something like libc+coreutils+util-linux+zlib+bzip2 (and probably more) ?

we could use some kind of repository of metapackages that would reference certain commonly encountered sets, as now it's mostly trial and error and i often end up with sce's duplicating certain libraries, despite my best efforts not to.

i would really like as little things reused as possible between sce's. obviously best way might be 1:1 deb-sce conversion, but it would be very mundane task.

Jason W:
If we ask 10 people what makes up a basic system, we would get 10 different answers.  Same with a desktop, network, or ultimedia collection.  Most folks here recognize the base and busybox as a basic system.  I know what you are saying though.  I would rather have a thread where folks posted package lists that make up their preference of a base, small desktop, large desktop, office, multimedia, etc.  One can just copy and paste that list and import it.

As for duplicating files and libraries, that does not happen when using the dependency option which is the whole point of the recent changes.   Regardless of the size of an sce, if it is used as a dependency then there will be no duplicate packages between it and sce's that are imported using it id as a dep.  If you have a base.sce and use it as a dep for a desktop.sce, then any package dependencies needed by desktop.sce that are in base.sce will not be included in desktop.sce since they exist in base.sce.  And if you import multimedia.sce using desktop.sce, then any package dependencies needed by multimedia that are in either base.sce or desktop.sce will not be included in multimedia.  And so on and so forth, use multimedia.sce as a dep and any packages existing in base, desktop, and multimedia will not be included in the resulting sce.  This goes for meta sce's as well as actual packages.

If libraries are being duplicated between sce's that are imported using the "-d" option, that is a bug and please report the specifics. 

Thanks.

Jason W:
Added the ability to deal with circular dependencies, a safety measure.  Please test.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version