| 1 |
I don't know about an automated process, there are a lot of variables |
| 2 |
that can factor into a version bump. However, for many simple |
| 3 |
packages, i.e. things that are not heavily patched or that do not have |
| 4 |
changing software requirements, it is usually sufficient to simply |
| 5 |
copy the old ebuild over to the new version name. |
| 6 |
|
| 7 |
Example, suppose net-www/fooapp has recently been bumped from version |
| 8 |
1.001 to 1.002. You could do the following: |
| 9 |
|
| 10 |
mkdir -p /usr/local/portage/net-www |
| 11 |
cp -r /usr/portage/net-www/fooapp /usr/local/portage/net-www |
| 12 |
cd /usr/local/portage/net-www/fooapp |
| 13 |
cp fooapp-1.001.ebuild fooapp-1.002.ebuild |
| 14 |
ebuild fooapp-1.002.ebuild digest |
| 15 |
emerge -auv fooapp |
| 16 |
|
| 17 |
The reason for copying the entire /usr/portage/net-www/fooapp |
| 18 |
directory tree over is that there may be some patches or configuration |
| 19 |
files or such under the files/ subdirectory which are required by the |
| 20 |
ebuild. As I said, this procedure works a good 8 or 9 times out of 10 |
| 21 |
with simple ebuilds, sometimes some slight modifications are necessary |
| 22 |
and other times the modifications may be quite extensive. |
| 23 |
|
| 24 |
BTW, if you do discover a package that has a new version and you get a |
| 25 |
good working ebuild for the new version make sure that you post it to |
| 26 |
bugzilla so that a developer can get it into the tree. |
| 27 |
|
| 28 |
On 4/28/06, Steve Herber <herber@×××××.com> wrote: |
| 29 |
> Portage is great but... it depends upon a person to create a new ebuild |
| 30 |
> when a new version is released. |
| 31 |
> |
| 32 |
> There are two times when I would like a script to create an ebuild |
| 33 |
> automatically. I wonder if anyone has such a script or if someone is |
| 34 |
> working on such a script. |
| 35 |
> |
| 36 |
> Often a new software release is available from the home site but |
| 37 |
> portage has not been updated. I would like a script that would: |
| 38 |
> |
| 39 |
> check the source repository for a package |
| 40 |
> find the latest version |
| 41 |
> if the repository has a newer version |
| 42 |
> create an overlay with an ebuild for the new version |
| 43 |
> try to build the new package |
| 44 |
> |
| 45 |
> Other times I will hear about a new software package and I want to try |
| 46 |
> it out. I would like a script that would take a URL for the home site |
| 47 |
> as an argument and then would operate like the script above. |
| 48 |
> |
| 49 |
> If such scripts were available, it would be much easier to check out |
| 50 |
> new software releases. I could imagine a system that would scan |
| 51 |
> listings from freshmeat or other non-Gentoo site, build the ebuild and |
| 52 |
> try the package. In the simplest case you would get a go/no-go answer. |
| 53 |
> For the packages that download and build, you could try it out. If it |
| 54 |
> failed you could ignore it or try to figure out the problem. |
| 55 |
> |
| 56 |
> This is not an AMD64 problem, but I know the people on this list are |
| 57 |
> always pushing the Gentoo limits. So, thank you for your suggestions. |
| 58 |
> |
| 59 |
> Thanks, |
| 60 |
> |
| 61 |
> |
| 62 |
> Steve Herber herber@×××××.com work: 206-221-7262 |
| 63 |
> Security Engineer, UW Medicine, IT Services home: 425-454-2399 |
| 64 |
> -- |
| 65 |
> gentoo-amd64@g.o mailing list |
| 66 |
> |
| 67 |
> |
| 68 |
|
| 69 |
-- |
| 70 |
gentoo-amd64@g.o mailing list |
Archives