[arch-dev-public] we want to give x86_64 a new direction

Roman Kyrylych roman.kyrylych at gmail.com
Thu May 10 16:40:47 EDT 2007


2007/5/10, Andreas Radke <a.radke at arcor.de>:
> after beeing an official port as a 100% i686 clone with a common cvs we
> have seen that we can handle the workload with only 2 man in not a bad
> way but with tons of hours of rebuilding and uploading the packages. but
> we don't want that anymore. it's simply too much workload and a task we
> are tired to do. bringing on new packagers is harder than expected. repo
> cleanups and a possible not to far away start of pacbuild/repoman will
> not drop down the workload we would need. i686 devs are not able to
> handle 32bit stuff very well so i don't count on crossbuilds anymore.
> that's one reason.
>
> the other one is beeing an i686 clone depending on its (not
> well defined) goals makes me sick. i miss any freedom in my work. at
> least the poor i686 testing procedure is something i don't want to
> follow anymore. i got more and more afraid how chaotic the developement
> is going on whithout the possebility to change it. now i see things
> start changing what is very good. but it seems most devs want to keep
> i686 the compromise of beeing bleading edge + at least some stability.
>
> i haved proved to build a system almost from scratch to the quality we
> now have. we are no more behind i686. a big part of that goes to the
> i686 devs and their most times simple and working packages and the
> easiness to port them. the Arch tools are great.
>
> but my personal goals have changed. together with Daniel we have found
> a few people that would support us if can go our own way. We have
> worked out some initial goals:
>
> - we want Arch x86_64 the more conservative sister distribution of Arch
> - less bleading edge
> - still a rolling system with up to date packages
> - strict rules how packages go through a testing cycle
> - we expect a significant lower workload due to longer update cycles
>   and less post-release-fixing of broken stuff
> - only provide a basic core repo by the devs
> - setup some basic addon repos
> - open the addon repos to be maintained by the community and
>   reviewed/released by the developers untill community members have
>   proved to do it the same way. that's something where we are not sure
>   where i686 wants to go and if we will adopt it.
>
> - it would not be prepared to have an x86 port. but only one x86(i586?)
>   dev would be enough to rebuild that distro with some help by an
>   automated build system.
>
> All in all it would be nothing significant different from the port
> we now have but packages would be more selected and hit the repos later
> to ensure the improved stability.
>
> we want to do this all together with the ArchLinux developers and
> community. we want to keep using all the great tools and resources Arch
> already offers.
>
> the first step that would need to be done is to splitout our scm. i
> cannot image to keep working with a common scm. that's what now makes it
> the clone we don't want to have any longer.
>
> if you agree to give us that freedom back, i already have one good
> candidate for becoming a new x86_64 developer and several community
> members promised to help out. they all like our goals. at least that we
> will have some.

Few questions:

What x86_64 users should do with those current/extra packages that
won't go in your repo?
What will be the status of AUR?
Example: when there is package foobar-5.0 in AUR  that depends on
libabc-2.1 in our current/extra, but your arch64 repo will have only
libabc-2.0 (which has incompatable API) - user will have to downgrade
foobar PKGBUILD to 4.0 that compiles with libabc-2.0
(sorry if my explanation is confusing)
Do x86_64 TUs agree to maintain separate set of PKGBUILDs compiled
against your "stable" versions? And where to put those packages that
are not in your current/extra, but are in ours, so they cannot go to
Community?

-- 
Roman Kyrylych (Роман Кирилич)


More information about the arch-dev-public mailing list