[arch-dev-public] rebuilding the whole core repo

[Damir Perisa]

Sunday 21 October 2007, Travis Willard wrote:
 | On Sat, 20 Oct 2007 22:17:32 +0200
 |
 | Daniel Isenmann <daniel.isenmann at gmx.de> wrote:
 | > On Sat, 20 Oct 2007 13:36:41 +0200
 | >
 | > Andreas Radke <a.radke at arcor.de> wrote:
 | > > A new glibc 2.7 is out and it's time to build a new toolchain.
 | > > After each major glibc and gcc update it's recommended to
 | > > rebuild every pkg. Only that way you can make sure to get
 | > > latest (speed) improvements and fixes. This is no problem for
 | > > all non-rolling release distros. So far we haven't done this
 | > > before. But now we should try.
 | > >
 | > > ArchLinux community strongly depends on good internet
 | > > connections. So for most parts of the users this will be no
 | > > problem.
 | > >
 | > > My suggestion:
 | > >
 | > > 1) We rebuild the core repo. It's small enough to start there.
 | > >
 | > > We run a script increasing the pkgrel, run makeworld and
 | > > upload everything to testing.
 | > > I'm not sure if makeworld {core,lib,devel,support} will run
 | > > through. We should test it. We could still hack a simple
 | > > script doing the makepkg calls one by one in the order we
 | > > like. After some testing this whole bunch of packages would
 | > > move to core. Both needs to be done for i686 and x86_64.
 | > >
 | > > 2) The extra cleanup should be done meanwhile.
 | > >
 | > > 3) Rebuild extra repo and fix or kick broken packages.
 | > >
 | > > I could offer some systems to do the rebuilds. I only have
 | > > slow upload bandwidth.
 | > >
 | > > Thoughts? How could help out?
 | > >
 | > > -Andy
 | >
 | > I can help out. I have a good upload connection and I can offer
 | > some free time in the evenings. The script for automatically
 | > increasing the pkgrel have you get already from me.
 | >
 | > For need of other scripts, just let me know. I can hack
 | > something together.
 | >
 | > I think the process you described for rebuilding the whole core
 | > repo first is ok. I think, we should try it.
 |
 | I think, as well, for this we need to make sure that NOTHING is in
 | testing before we begin - ie. everything has been pushed back to
 | core or extra.  That will ensure that the PKGBUILDs in CVS are all
 | in a consistent state.
 
i agree. we should wait for testing to empty and then freeze the 
updating while rebuilding everything. one option would be to split it 
in stages... and spread them over e.g. 2 months, so that users do not 
have to download once a huge load of pkgs. (some providers limit 
ammount of free traffick)

 | If we're feeling REALLY ambitious, this would be a great time to
 | fix all the licenses in our packages - we still have over 1000 bad
 | licenses in extra - attached file shows packages that need work.

good idea... regarding your list i have some items:

* we should have the MIT licence in our common licences folder

* we should add all possible CC licences in our common licences 
folder ... maybe informing creative commons that we support their 
full scheme of licencing in our licence handling (public relations, 
networking *g*)

* LGPL2 = LGPL2.1 ? and if some pkg uses 2.0? our LGPL2 is indeed the 
2.1 version 

* some pkgs have licence-formatting issues (Apache instead of APACHE 
or gpl instead of GPL ... we change the formating? licences are 
all-caps always?)

- D


-- 
.·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´
            °        °           °
             °      °            °
     ><((((º>      °              °
                    °            °
                   °            <º)))><
                  <º)))><