On Mon, 22 Oct 2007 15:00:59 +0200, Damir Perisa wrote
Sunday 21 October 2007, Travis Willard wrote: | On Sat, 20 Oct 2007 22:17:32 +0200 | | Daniel Isenmann <daniel.isenmann@gmx.de> wrote: | > On Sat, 20 Oct 2007 13:36:41 +0200 | > | > Andreas Radke <a.radke@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)
Good plan - people probably wouldn't appreciate downloading their entire system again in a single -Syu... but then there'll still be some people who wait 2 or 3 months to upgrade, so we can't accomodate everyone, unfortunately.
| 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*)
Regarding the above two, I'm all for adding common licenses (MIT, CC) to the licenses package, provided we can - I remember some licenses that are pretty common actually differ in their text from package to package (ie. the devs of the software need to add their own info for copyrights or something) - we can't really provide a common license for those.
* LGPL2 = LGPL2.1 ? and if some pkg uses 2.0? our LGPL2 is indeed the 2.1 version
How significant are the differences between 2.0 and 2.1? Isn't our GPL2 license 2.1 as well?
* some pkgs have licence-formatting issues (Apache instead of APACHE or gpl instead of GPL ... we change the formating? licences are all-caps always?)
The script I used to generate that list checked, for each license in licenses, is it "custom"? If not, then does a folder structure exist at /usr/share/licenses/common/${license}? If no, then it's invalid. Since the folders in /usr/share/licenses/common are capitalized, I think the entries in the license array should be as well. -- Travis