Development features

[Toan Pham]

Hi all,

I am a T2SDE user for about 5 years now, and I feel like there are some
features that the SDE is missing, and they need to be addressed. Such
features are:


1. Better Dependency tracking policy.
i. We need a be able to specify package dependency in three
categories: build time, runtime/hard-dependency, and optional/feature
dependency.
a. Build time dependencies are dependency generally needed to
build a package (autoconf, perl etc...)
b. runtime - must have dependency
c. optional - dependency we should identify to make sure that
are essential if a feature of a package is turned on, for example.


ii. Note, if we do it right, for example integrate SDE linker wrapper
to detect build time, and runtime dependencies for us. It is a method to
verify not only if we really have real dependencies in our package
dependency database, but also useful to create a _REAL_ dependency graph of
the root-filesystem.


2. Support patches based on package version.
i. This is a really nice feature that buildroot has, and I feel the
SDE is missing.

3. Right now, i notice that the SDE is very sensitive to what system it
is running on, ie ubuntu or sde-8.0. I am wondering if we should consider
building a bootstrap SDE environment at stage say, -1. that way, it
wouldn't give beginners too much problems getting started.


I'd like to know if there are people out there like to improve the SDE
tool. I feel that if we were to improve the tool, it would take alot of
work load off for us in terms of maintaining the package updates, and build
bug fixes.


thank you,

Toan

[ExactCODE]

Hi Toan,
I am curious - do you use T2 for embedded projects, or for your personal workstation / servers?

Post by Toan Pham
1. Better Dependency tracking policy.
i. We need a be able to specify package dependency in three categories: build time, runtime/hard-dependency, and optional/feature dependency.
a. Build time dependencies are dependency generally needed to build a package (autoconf, perl etc...)
b. runtime - must have dependency
c. optional - dependency we should identify to make sure that are essential if a feature of a package is turned on, for example.
ii. Note, if we do it right, for example integrate SDE linker wrapper to detect build time, and runtime dependencies for us. It is a method to verify not only if we really have real dependencies in our package dependency database, but also useful to create a _REAL_ dependency graph of the root-filesystem.

Yes, extending the dependency tracking like this was on our TODO / roadmap for quite some time. I personally did not had so much use for that recently, so I do not yet personally implement more of this.

Do you want this run-time emerge (e.g. graphic workstation or server) or easier define embedded targets?

[patches welcome]

Post by Toan Pham
2. Support patches based on package version.
i. This is a really nice feature that buildroot has, and I feel the SDE is missing

Well, I am not such a big fan of this. It is already enough work to keep mostly-recent versions working and building. Adding even more variants to the mix does not feel like much value. Especially given nowadays common security breaches of old versions of libs, languages, etc. One should rather use newer stuff than older.

For big packages where major versions break things we already have gtk+ gtk+12, or qt3, qt4, and now qt5, …

A decade ago at ROCK Linux times this was tried in the end. E.g. with compiler versions gcc{2,3,34} etc. But honestly this is so much enormous work for little gain, and at the end of the day most combinations will result in subtile build errors.

Post by Toan Pham
3. Right now, i notice that the SDE is very sensitive to what system it is running on, ie ubuntu or sde-8.0. I am wondering if we should consider building a bootstrap SDE environment at stage say, -1. that way, it wouldn't give beginners too much problems getting started.

We already have exactly this, the stage 0 is bootstrapping clean build tools.

That it sometimes does not work is mostly a result of bizarre bugs and breakage of traditional Unix tool behavior on some distributions, …

[patches welcome]

Post by Toan Pham
I'd like to know if there are people out there like to improve the SDE tool. I feel that if we were to improve the tool, it would take alot of work load off for us in terms of maintaining the package updates, and build bug fixes.

Especially the patches per package version I only see as exponentially increasing work. Packages updates usually already are as as easy as:

scripts/Update-Pkg llvm 3.5.0

And frankly, I have the feeling Gerardo Di Iorio and me are more or less the only ones doing the maintenance work at this time anyway, … ?

That said: patches for anything more than welcome!

René