19 Dec
2005
19 Dec
'05
6:32 p.m.
Hi Daniel,
On Mon, Dec 19, 2005 at 19:14:04 +0100, Daniel Mueller wrote:
> On Monday 19 December 2005 13:55, Johannes Winkelmann wrote:
>
> > 1. The user only gets ports tested on this platform
>
> yep.
>
> > 2. The user gets the same system on every system
>
> This is not possible. Lilo doesn't work on all platforms and devfs was thrown
> out of the kernel source tree. Library paths differ from $arch to $arch and
> configuration files sometimes need special adjustments.
Oh, you took my words too literarily.
What I meant is that it's /usr/ports/{core,opt,contrib} on every arch
for example.
The PPC team seems to be in favour of a /usr/ports/{x86,ppc} special
solution on their system; it's more this kind of things I mean.
Of course, ports have to be chosen per plaform, changes have to be made
for pathes and so an. As for devfs, that's not really an issue of archs;
if we had sync'ed released, all archs would have udev.
I would however be in favour that all archs have more or less the same
features in their ports; as a silly example, let's say mplayer is build
without GUI on all archs. However, I think that's already the case now.
> > 3. No single master tree (as it is now)
>
> Mhh, a separated ports tree would be nice. A mechanism which prevents me from
> accidently touching x86 ports :-)
It will also allow us to distribute the primary maintenance (following
the mailing lists, checking for announcements and conflicts) to several
architectures, making it easier to maintain a port on a another
architecture (let's say I maintain libxml2 on sparc which you maintain
on x86_64; in this case, I can simply follow your port, but not the
libxml2 mailing list).
> > 4. The package management stays as easy as it is now (i.e. no special
> > cases)
>
> :-(
>
> I'm not allowed to write a 'patch-helper' function in special cases? It's
> annoying to write fifteen 'patch -p1 < $SRC/no1.patch' lines.
Peanuts :-). What I meant here was that it's not something like:
If you execute pkgmk, it will
1. check for Pkgfile.$arch, and build it if it's there
2. choose Pkgfile otherwise
and the same for md5sum and footprint
That's what I meant with special cases for the package management. I'm
mainly against this since the users who look for an error in a build
will have to go through the same process: "where's the error, is it in
Pkgfile.$arch, or in Pkgfile...".
> > 5. Allow to start ports to new architectures easily, without requiring
> > too many developers
>
> What do you mean?
Basically two things.
1. that in order to start an architecture which only reuses ports from
the other architectures and requires little work (i.e. provide a sync
tool which is adapted to our needs).
2. that the setup allows to start working on it without requiring
special accounts or rights. The typical situation would be to have a
central SVN repo, where everything's developed and users need write
permissions to start working on a new archtecture.
Well, I guess my initial mail wasn't too clear then :-). Sorry for that,
and thanks for your questions, I hope I could clear up my previous mail
a bit.
Kind regards, Johannes
--
Johannes Winkelmann mailto:jw@tks6.net
Bern, Switzerland http://jw.tks6.net