Hi. This is the qmail-send program at mail.netbeat.de.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<j4y54w@sawinski.de>:
failed to write delivered to line errno=28
--- Below this line is a copy of the message.
Return-Path: <karasz@x5.ro>
Received: (qmail 14760 invoked from network); 10 Dec 2005 21:04:12 -0000
Received: from mx01.qsc.de (213.148.129.14)
by mail.netbeat.de with SMTP; 10 Dec 2005 21:04:12 -0000
Received: from port-212-202-42-30.dynamic.qsc.de ([212.202.42.30] helo=exactcode.de)
by mx01.qsc.de with esmtp (Exim 3.35 #1)
id 1ElBrM-0006vf-00; Sat, 10 Dec 2005 22:02:24 +0100
Received: from localhost
([127.0.0.1] helo=exactcode.de ident=root)
by exactcode.de with smtp (Exim 4.54)
id 1ElBr7-0002xJ-0V; Sat, 10 Dec 2005 21:02:09 +0000
Received: (nullmailer pid 11357 invoked by uid 2000);
Sat, 10 Dec 2005 21:02:06 -0000
Received: from [80.97.102.201] (helo=expert-software.ro)
by exactcode.de with esmtp (Exim 4.54)
id 1ElBqK-0002ww-1q
for t2@t2-project.org; Sat, 10 Dec 2005 21:01:21 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
by expert-software.ro (Postfix) with ESMTP id 610E2BA936
for <t2@t2-project.org>; Sat, 10 Dec 2005 22:22:11 +0200 (EET)
Received: from expert-software.ro ([127.0.0.1])
by localhost (expert-software.ro [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 01163-09 for <t2@t2-project.org>;
Sat, 10 Dec 2005 22:21:50 +0200 (EET)
Received: from [192.168.1.3] (unknown [80.97.102.202])
by expert-software.ro (Postfix) with ESMTP id C9F73BA929
for <t2@t2-project.org>; Sat, 10 Dec 2005 22:21:50 +0200 (EET)
Message-ID: <439B3A6A.4030409@x5.ro>
Date: Sat, 10 Dec 2005 22:28:26 +0200
From: karasz <karasz@x5.ro>
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
References: <439AE005.2040704@x5.ro> <439B3197.1030106@geeks.cl>
In-Reply-To: <439B3197.1030106@geeks.cl>
X-Virus-Scanned: amavisd-new at expert-software.ro
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam detection software, running on the system "grum.localhost", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Alejandro Mery wrote: > karasz wrote: >> Hi, >> >> First
of all i guess that we should make a clear separation >> between T2 SDE
and the T2 powered targets/distros. >> What are the components of T2
SDE? Surely the scripts belong to >> the SDE but what about the package
structure, i mean the .desc and >> .conf files? They belong to the SDE
or to the targets/distros? > > every package/*/*/ at t2 svn (i.e., not
external) belongs to T2 > 'database'. > >> And now about SAM the tool
for distro mantainers: >> In my opinion a tool for binary updates of
your distro is >> essential, without that targets or T2 powered distros
will suffer the >> faith of source based distros which can't get
acceptance outside the >> hackers/geeks comunities. > > ack > >> So SAM
is a very wellcomed adition to T2 base. But it raises some >> questions:
>> How will relate the distros binary pools to the actual package
section? >> Let's make a scenario: >> 1. Guy makes a distro using T2 SDE
he names it `Miruna` (don't ask >> why, just bare with me). >> 2. He
build Miruna regarding the following matrix: >> 2.1 Packages: kernel
2.6.13, mc 1.5.0, PostgreSQL 8.1.1 >> 2.2 Platforms: x86(Pentiun 4) ,
AMD-64 and PowerPC64 >> 3. The packages are built using .conf and .desc
from a mix of >> T2-stable and T2-trunk, and some of them do not even
belong to T2 >> (this he should contribute, right? ;) ) > >
package/contrib/ is currently for toy packages > > if Miruna has a
private package repo you could set package/miruna/ as > external, just
like the target. but it's always better to have all > packages at T2 to
avoid duplication. > > >> 4. He mantain a poll for his distro (containig
packs built for every >> platform he supports) and he keeps it on _his
server_ (or it will be >> on some T2 afiliated server? this requires a
lot of webspace which is >> expensiove i guess) >> 5. His server is a
single point of failure for updates in this case >> (or he must provide
mirrors? this is not very easy for individuals or >> small firms). > >
distribution can publish a l [...]
Content analysis details: (0.0 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
To: T2 developers mailing list <t2@t2-project.org>
Precedence: list
X-BeenThere: t2@t2-project.org
Subject: Re: [t2] About SAM
List-Id: t2 Mailing List <t2@t2-project.org>
List-Help: <mailto:minimalist@t2-project.org?subject=help>
List-Subscribe: <mailto:minimalist@t2-project.org?subject=subscribe%20t2>
List-Unsubscribe: <mailto:minimalist@t2-project.org?subject=unsubscribe%20t2>
List-Post: <mailto:t2@t2-project.org>
List-Owner: <mailto:t2-owner@t2-project.org>
Errors-To: info@t2-project.org
X-List-Server: Minimalist v2.5(2.3) (Chernigov White) <http://www.mml.org.ua/>
Content-Type: multipart/mixed;
boundary="MML_1134248524_11351@3079.t2-project.org"
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam detection software, running on the system "grum.localhost", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Alejandro Mery wrote: > karasz wrote: >> Hi, >> >> First
of all i guess that we should make a clear separation >> between T2 SDE
and the T2 powered targets/distros. >> What are the components of T2
SDE? Surely the scripts belong to >> the SDE but what about the package
structure, i mean the .desc and >> .conf files? They belong to the SDE
or to the targets/distros? > > every package/*/*/ at t2 svn (i.e., not
external) belongs to T2 > 'database'. > >> And now about SAM the tool
for distro mantainers: >> In my opinion a tool for binary updates of
your distro is >> essential, without that targets or T2 powered distros
will suffer the >> faith of source based distros which can't get
acceptance outside the >> hackers/geeks comunities. > > ack > >> So SAM
is a very wellcomed adition to T2 base. But it raises some >> questions:
>> How will relate the distros binary pools to the actual package
section? >> Let's make a scenario: >> 1. Guy makes a distro using T2 SDE
he names it `Miruna` (don't ask >> why, just bare with me). >> 2. He
build Miruna regarding the following matrix: >> 2.1 Packages: kernel
2.6.13, mc 1.5.0, PostgreSQL 8.1.1 >> 2.2 Platforms: x86(Pentiun 4) ,
AMD-64 and PowerPC64 >> 3. The packages are built using .conf and .desc
from a mix of >> T2-stable and T2-trunk, and some of them do not even
belong to T2 >> (this he should contribute, right? ;) ) > >
package/contrib/ is currently for toy packages > > if Miruna has a
private package repo you could set package/miruna/ as > external, just
like the target. but it's always better to have all > packages at T2 to
avoid duplication. > > >> 4. He mantain a poll for his distro (containig
packs built for every >> platform he supports) and he keeps it on _his
server_ (or it will be >> on some T2 afiliated server? this requires a
lot of webspace which is >> expensiove i guess) >> 5. His server is a
single point of failure for updates in this case >> (or he must provide
mirrors? this is not very easy for individuals or >> small firms). > >
distribution can publish a l [...]
Content analysis details: (0.0 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
This is a multi-part message in MIME format.
--MML_1134248524_11351@3079.t2-project.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Alejandro Mery wrote:
> > karasz wrote:
>> >> Hi,
>> >>
>> >> First of all i guess that we should make a clear separation=20
>> >> between T2 SDE and the T2 powered targets/distros.
>> >> What are the components of T2 SDE? Surely the scripts belong to=20
>> >> the SDE but what about the package structure, i mean the .desc and=20
>> >> .conf files? They belong to the SDE or to the targets/distros?
> >
> > every package/*/*/ at t2 svn (i.e., not external) belongs to T2=20
> > 'database'.
> >
>> >> And now about SAM the tool for distro mantainers:
>> >> In my opinion a tool for binary updates of your distro is=20
>> >> essential, without that targets or T2 powered distros will suffer the=20
>> >> faith of source based distros which can't get acceptance outside the=20
>> >> hackers/geeks comunities.
> >
> > ack
> >
>> >> So SAM is a very wellcomed adition to T2 base. But it raises some=20
>> >> questions:
>> >> How will relate the distros binary pools to the actual package section=
?
>> >> Let's make a scenario:
>> >> 1. Guy makes a distro using T2 SDE he names it `Miruna` (don't ask=20
>> >> why, just bare with me).
>> >> 2. He build Miruna regarding the following matrix:
>> >> 2.1 Packages: kernel 2.6.13, mc 1.5.0, PostgreSQL 8.1.1
>> >> 2.2 Platforms: x86(Pentiun 4) , AMD-64 and PowerPC64
>> >> 3. The packages are built using .conf and .desc from a mix of=20
>> >> T2-stable and T2-trunk, and some of them do not even belong to T2=20
>> >> (this he should contribute, right? ;) )
> >
> > package/contrib/ is currently for toy packages
> >
> > if Miruna has a private package repo you could set package/miruna/ as=20
> > external, just like the target. but it's always better to have all=20
> > packages at T2 to avoid duplication.
> >
> >
>> >> 4. He mantain a poll for his distro (containig packs built for every=20
>> >> platform he supports) and he keeps it on _his server_ (or it will be=20
>> >> on some T2 afiliated server? this requires a lot of webspace which is=20
>> >> expensiove i guess)
>> >> 5. His server is a single point of failure for updates in this case=20
>> >> (or he must provide mirrors? this is not very easy for individuals or=20
>> >> small firms).
> >
> > distribution can publish a list of updated download mirrors, only one=20
> > for small ones, or do the trick by dns. and packages PGP signed, and a=20
> > set of signatures to build the ring injected on sam's build time. same=20
> > for the url of the mirror list.
> >
>> >> 6. What about mantaining a central repository of packages regardless=20
>> >> to distros? every package for every platform supported by T2 so that=20
>> >> binary updates regardless of the distro can be made more securely.
> >
> > that's what can't be done simply because binary package foo on target=20
> > `Miruna` and binary package foo on target `Marrana` can be completely=20
> > differente even if the have the same version and optimization. prefix=20
> > can differ, config can differ, patches can differ, dependencies can=20
> > differ, etc.
> >
In this case i guess that mantainer's word rules. If mantainer selects
prefix, config, patches or deps than that it is. Those should be
unuversaly valabile. If you do not agree with those than you can allways
build from source and forget about binary updates.
>> >> By more securely i mean that mantainers should mantain packages=20
>> >> and not entire distros, now they are mantaining packages right?
> >
> > package maintainers are responsable to keeping packages updated,=20
> > building and integrated with T2 flexibility so target/distribution=20
> > maintainers only have to worry about keeping a good package selection=20
> > for their 'target usage' and adding services/interface/life usability=20
> > improvements specific to their goal.
> >
Question: evry target will use some packs (i.e. kernel, ssh) who will
provide binary updates for them? The T2 mantainer of the pack or the
distro mantainer?
If it is the T2 mantainer then we have a problem because binary updates
will come from two places at least, but maybe more.
If it is the distro mantainer than we have another problem because pack
have two or more `fathers` and i gues that this is not ideal...
>> >> it is more fesable to mentain some packages and know the inner=20
>> >> working of them than to solely mantain a whole distro.
>> >> In this scenario a package is tied to a man and it relinquish the=20
>> >> redundance of several people mantaining the same package eventualy in=20
>> >> different versions, which is bad i guess.
> >
> > final binary packages differ a lot from one target to another, that's=20
> > why we cannot share them inter 'distribution'.
> >
They should not differ except the platform. I gues tha we can agree upon
a general rule set for optimizations and patches for packs. If someone
does not like it he can allways use source instals isn't he?
> >
> > Regards,
> > Alejandro Mery
> >
Respectfuly,
Nagy K=E1roly Gabriel
--MML_1134248524_11351@3079.t2-project.org
Content-Type: text/plain; charset=us-ascii; name="footer"
Content-Transfer-Encoding: 8bit
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
lists@t2-project.org with a subject of: unsubscribe t2
--MML_1134248524_11351@3079.t2-project.org--