Hi,
just a brief reply (I'm abroad, maybe others can contribute with
answers in more
detail).
On 01.06.2008, at 17:46, Tobias Geerinckx wrote:
A good day to all,
I'll of course begin with the obligatory but no less sincere "thank
you" for putting what must be an incredible amount of time & effort
into T2. From what I've seen so far it seems about as "clean" and up-
to-date as any large scale build project can ever be (though I'll be
the first to admit my bash-grokking abilities are sadly sub-par,
explaining some questions below :-)
I've been an avid Gentoo user for several years but a combination of
slight dissatisfaction regarding its current direction and general
curiosity keep me on the lookout for possible alternatives such as
T2. Minimum requirements include using the same code base for all my
machines (a desktop and two sub-notebooks), full customization of
each installed system, being able to cross-build everything on a
single fast [desktop] system, and easy upgrading/distribution of
binary packages to the notebooks. T2 seems to be able to provide all
that and more.
However, I still have some questions regarding:
* building SCM packages: the T2 package/ directory has quite a few
packages that get their sources via CVS/SVN/&c. I was only able to
spend a brief time checking out T2 (with no access at the moment,
sorry), but did notice scripts/Download wrapped the final sources in
a .tar.bz2 when finished. My question: does this .tar.bz2 contain
the entire working copy (with SCM metadata, e.g. ".svn" directories)
or only the sources (e.g. "svn export"> tar> bz2)? If the latter, is
the orginal working copy saved alongside or will incrementing the
revision number in the .conf file lead to re-downloading the entire
package sources instead of just a delta? Traffic doesn't come
completely for free here, and still I'd like to be able to follow
KDE4 trunk without having to keep track of installed files manually.
Currently the SCM files are not included in the tarball, to keep the
size down on
our mirrors and for end-user downloads.
For developers it might indeed be nice to use full (not exported)
tree's, maybe
we should add an option for this.
* also regarding SCM packages: can I simply tell T2 to scripts/
Download the "latest" revision instead of a manually specified rev.
# on the [D] line?
Not on the command line, but by either updating the package meta data,
or creating
your own target overlay defining the new revision.
* reverse dependencies: the general consensus on enabling/disabling
functionality in packages (comparable to Gentoo's "use flags", e.g.
USB support) seems to be including/excluding the library
implementing that feature (e.g. entering "- libusb" in scripts/
Config> Custom package selection). Is this correct, and what if USB
were to prove necessary after all? Does T2 know which packages
decided to disable USB support based on the then-absent libusb
during "configure" and build them again? If not built in, can such
functionality be scripted using the info provided by the build system?
On the those package dependencies are selected based on installed
packages.
T2 does right now not store information about features disabled due to
un-
selected / not-installed packages. However, as the exactly same
feature was
requested during our Linux Tag exhibition we apparently should add it to
our TODO list.
* deployment & updating: the correct method to build the initial
install ISOs seems to be Config ; Build-Target ; Create-ISO. After
installing, "svn up [package/]" will get me the newest build
scripts. Is there a command that will build & create binary packages
for each updated package, or at least a list to pass to Emerge-Pkg?
Or am I misunderstanding the way updating works once "inside" the T2
system?
Emerge-Pkg -system can be used to update the system on-the-fly (a Gentoo
a-like way).
If you actually really want to generate a new ISO for "distribution"
you can
also do this, by flushing updated packages from the build sandbox:
./scripts/Create-ErrList [ -cfg a-config-name ] -newremove
Create-ErrList generally prints a pretty table about the build errors.
The
-newremove option wipes the log files controlling which packages are
to be build and thus a Build-Target just builds the updated packages.
I hope all these (probably stupid & uninformed :-) end-user
questions don't constitute spamming this rather-dev list, and I
apologize if they do...
You're welcome and all this are quite valid questions, and for some
we should even add some new code.
The t2 list is at times rather low-volume and until we get linux-kernel
levels intended for user questions just as well :-)
Greetings,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of: unsubscribe t2
