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

[yoshi314]

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.

That i understand, and that works just fine. My problem is that so far no matter how i try, multiple packages will still share quite a lot of low level system packages that compose undefined base set, that i have to figure out by trial and error.

So far that set entails coreutils, zlib1g, bzip2, util-linux, gcc-base, libc6-bin, e2fsprogs and i am not sure what else. I keep seeing packages duplicating those debs, and to minimize duplication i have to redo my bottom level sce's. Finding that common denominator is mostly done through experimentation.

I would just like to have something resembling a system set of debootstrap wrapped up in one sce, but i am not sure if that is defined as package set. That would greatly shrink other sce's i am deriving from it.

[Jason W]

Have you re-imported all your sce's from scratch?  Because no matter how low level a package is, it should not be duplicated by dependent sce's..

[yoshi314]

Have you re-imported all your sce's from scratch?  Because no matter how low level a package is, it should not be duplicated by dependent sce's..

no i am digressing about something else. there is no duplication between sce and its dependent packages.

i thought about that there are lots of low level packages introduced into each package's dependencies (exluding those you provide in dependencies). i wondered if there is no defined set for that base system in debian or a dcore metapackage of sorts for it.

[Jason W]

I see you are wanting for there to be a meta "base" package that would eliminate lower level packages from being included in higher level apps. 

What I recommend is to install your favorite sets of apps using the dependency option, then go through those apps and find which libs you don't want duplicated across the higher level apps.  Say both firefox and leafpad and emelfm2 contain libc6.  Then libc6 is one you would want in your base.

Ok, I will look at CorePlus and perhaps base some meat package sets on it's selection.

[Jason W]

If no more bug reports, I will keep testing here and if I don't find anything I will make a release for x86 and Allwinner.

[netnomad]

hi jason w,

sounds good and i like it!

perhaps you want to touch these two missing files?
tc@box:~/tmp$ touch .scedebs
tc@box:~/tmp$ touch .scedeps

or is it too quick and dirty?

thank you for your help and commitment.

[Jason W]

Oh, yeah, those 2 files.  I will find where they are being echoed and fix it.

[Jason W]

I think I found it.  Uploaded a new cut to release candidates.

[Jason W]

Fixed a bug, uploaded new dCore.gz to release candidates.

[netnomad]

hi jason w,

all works flawless for me.

this is an excellent milestone and gives a path to a highly usable dCore-system for every-day-tasks and highly specified applications.

thank you, keep on hacking

[Jason W]

Great, it is working here too.  I have some other ideas, but at this point I think we have a well tested set of changes that qualifies for a release.  I will put it up tomorrow.