Re: Desktop user (hopefully) switching from Gentoo

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
lists@xxxxxxxxxxxxxx with a subject of: unsubscribe t2