Thanks for your really quick replies. You missed question 2c) ....
----------------------------------------
> Date: Tue, 18 Dec 2007 08:02:39 +1300
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: [yoper-dev] [PACKAGERS] - Some hints to mass migrate
> CC: yoper-dev@lists.yoper.com
>
> 2007/12/18, Carlos López :
>>
>> Hi Tobias,
>>
>> good mini-guide. However, not to break the normal rule, I have a few
>> questions:
>> ----------------------------------------
>>> Date: Tue, 18 Dec 2007 07:07:34 +1300
>>> From: [EMAIL PROTECTED]
>>> To: yoper-dev@lists.yoper.com
>>> Subject: [yoper-dev] [PACKAGERS] - Some hints to mass migrate
>>>
>>> Hi,
>>>
>>>
>>> As this is the first time we do that in this configuration I'd like to
>>> suggest a certain approach.
>>>
>>> 1) Do not migrate more than 20 packages at once ( svn cp )
>>
>> I think one bye one is even better. Migrating packages from 3.0 to 3.1 is
>> not such a direct task, even more taking into account that g++ is not now in
>> gcc package and that we have to upgrade quite old packages. We have also to
>> remember that neither .la files nor buildroot is working in the same way.
>
> Yes, this is true. The number 20 was the upper limit I was suggesting.
> Choose less if you're more comfortable with that. There will be 20
> packages that you migrate within a hour while the next 20 packages
> might take a week.
>
> The problem is more avoiding that we all start migrating the same
> packages. Maybe a quick mail when doing mass migration of some
> packages would help to avoid that. I started mass migration with a* .
>
> Another catch is , that we have to look in those 20 packages now and
> make sure we migrate their dependencies first.
>
>>
>>> 2) Make things in small steps
>>> a) copy package A
>>> b) bump release and get a successful build done for package A
>>> c) test new package briefly and confirm functionality
>> How is it supposed to do this having Yoper 3.0 in our machines? Aren't
>> packages for 3.1 incompatible for 3.0?
>>
>>> d) update package to latest stable version and get a successful build
>>> done
>>> e) update dependencies of this package A if necessary
>> Is there any rule of thumb to do this? When should a dependency be
>> considered that must be rebuilt or might be affected by the new build?
>
> Major version update or when you see that when installing a new
> version of a package would uninstall some other packages. If there's
> no version update you generally don't need to rebuild any packages.
>
>>
>>> 3) move to package B
>>>
>>>
>>> If you hit problems with a package that is not in your maintainership
>>> contact the maintainer or the mailing list and give 24 hours time to
>>> respond before proceeding.
>>>
>>> Packages that do not have a current maintainer need to get the vacant tag.
>>>
>>> Some suggestions how to do things in detail. We have some useful
>>> helpers in our svn tree to make things a bit easier:
>>>
>>> 1) svn-cp-tree.sh , copies a whole bunch of projects into --targetdir
>>>
>>> it supports --dry-run to test the command
>>>
>>> When used it copies the mentioned projects and performs a svn ci -m
>>> 'commitonly' of all packages that are successfully copied.
>>>
>>> Here an example :
>>>
>>> ~/versioncontrol/svn/yoper/projects/errata/svn-cp-tree.sh
>>> --targetdir=../../3.1/rocketfuel/ aMule abiword acpid add airsnort
>>> alien alltray alsa-utils amsn appres apt4rpm aquamarine arping ash
>>> aspell at-spi atftp athcool aufs autoconf261 automake110 automake16
>>> autotrace
>>>
>>> Just simply note the revision number somewhere and you can always look
>>> back via svn log -v -rREVNO to see which packages you copied :) .
>>>
>>>
>>> 2) bump-buildreq.sh
>>>
>>> Use this to bump the release of packages that depend on a certain
>>> package. For example if you'd like to bump all packages in
>>> 3.1/rocketfuel that are build against sqlite execute :
>>>
>>> ~/versioncontrol/svn/yoper/projects/errata/bump-buildreq.sh sqlite-devel
>>>
>>> This will bump the release of those packages by 1 and generate a svn
>>> command that you can simply copy and paste.
>>>
>>> it supports --dry-run to test the command
>>> 3) bump-release.sh
>>>
>>> This script bumps projects that are appended to it as arguments.
>>>
>>> it supports --dry-run to test the command
>>>
>>> This allows you to selectively bump the release of some packages
>>>
>>> Say you want to first see where sqlite-devel is included :
>>>
>>> grep -l sqlite-devel */*.spec | awk -F '/' '{print $1}'
>>>
>>> This will return you some project names where you might not want to
>>> bump all packages but only a few.
>>>
>>> That is where script (3) is useful simply run
>>>
>>> bump-release.sh 'your list of projects to bump release'
>>>
>>> I hope this helps a bit to decrease the workload and simplify the
>>> task. More input welcome.
>>>
>>> cheers
>>
>> Cheers x 2! :-)
>>> --
>>> Tobias Gerschner
>>> Member of Board of Yoper Linux Ltd. NZ
>>>
>>> Knowing is not enough; we must apply. Willing is not enough; we must do.
>>> _______________________________________________
>>> yoper-dev mailing list
>>> yoper-dev@lists.yoper.com
>>> http://lists.frank-hosting.de/cgi-bin/mailman/listinfo/yoper-dev
>>
>> _________________________________________________________________
>> Tecnología, moda, motor, viajes,…suscríbete a nuestros boletines para estar
>> siempre a la última
>> http://newsletters.msn.com/hm/maintenanceeses.asp?L=ES&C=ES&P=WCMaintenance&Brand=WL&RU=http%3a%2f%2fmail.live.com
>
>
> cheers
>
> --
> Tobias Gerschner
> Member of Board of Yoper Linux Ltd. NZ
>
> Knowing is not enough; we must apply. Willing is not enough; we must do.
_________________________________________________________________
Tecnología, moda, motor, viajes,…suscríbete a nuestros boletines para estar
siempre a la última
http://newsletters.msn.com/hm/maintenanceeses.asp?L=ES&C=ES&P=WCMaintenance&Brand=WL&RU=http%3a%2f%2fmail.live.com
_______________________________________________
yoper-dev mailing list
yoper-dev@lists.yoper.com
http://lists.frank-hosting.de/cgi-bin/mailman/listinfo/yoper-dev
