1 |
On Sat, 2006-05-13 at 01:55 -0400, Ned Ludd wrote: |
2 |
> On Fri, 2006-05-12 at 16:05 -0700, Nimish Pachapurkar wrote: |
3 |
> > Hello All, |
4 |
> > |
5 |
> > I have been fiddling with Portage for a few weeks now. Recently, I was |
6 |
> > trying to get the RPM creation with ebuild to work a little better. I |
7 |
> > noticed that currently emerge does not support building RPMs, but ebuild |
8 |
> > does. |
9 |
> > |
10 |
> > I have added some code to emerge that can build RPM for a package and |
11 |
> > all its dependencies. It will optionally merge the package to the system |
12 |
> > or just build an RPM. I am basically making this work very similar to |
13 |
> > the --buildpkg and --buildpkgonly options. |
14 |
> > |
15 |
> > I am using --buildrpm (-r) and --buildrpmonly (-R) options currently for |
16 |
> > these two tasks. However, if those two short options are reserved for |
17 |
> > some other purpose, I am fine with changing them. (If so, please suggest |
18 |
> > different short options). |
19 |
> > |
20 |
> > If this functionality is likely to be useful to other people also, I |
21 |
> > would love to submit a patch. |
22 |
> > |
23 |
> > I think I have somewhat older version of portage. Which version should I |
24 |
> > build the patch against, if I have to? |
25 |
> |
26 |
> |
27 |
> 2.1 is in a feature freeze right now. Everybody is trying to tidy up |
28 |
> existing functionality in preparation for 2006.1 But that would of |
29 |
> otherwise been the branch of seen it committed to. probably best to |
30 |
> give it a few weeks and revisit. |
31 |
> |
32 |
|
33 |
Sure, I will do that. |
34 |
|
35 |
> rpm support however needs more than a few emerge switches. The existing |
36 |
> package itself of rpm in the tree has a few problems and really needs a |
37 |
> maintainer. Also portage's auto spec generation is on the side of far |
38 |
> to basic to really be useful. |
39 |
> |
40 |
|
41 |
I have realized that already. I created a small tool in Python myself |
42 |
using gentoolkit to get RPM-style list of first-level (or direct) |
43 |
dependencies based on USE flags dynamically. It has been working well |
44 |
for most of the cases. Unfortunately, I did not find a clean way to use |
45 |
Portage dependency parsing. I could not find a way to get just the first |
46 |
level dependencies without resolving them to specific ebuild files. |
47 |
|
48 |
I also had to solve the SLOT problem since RPM will not let you install |
49 |
two packages with the same name at the same time. |
50 |
|
51 |
> A while ago a user Peter S. Mazinger <ps.m@×××.net> and myself |
52 |
> discussed in semi detail a lot of the problems surrounding rpm support |
53 |
> and later he sent me some patches that interpolated nicely with the |
54 |
> existing rpm based distros. I mirrored those patches and they are |
55 |
> all tagged with the names of the portage-rpm-*.patch |
56 |
> http://dev.gentoo.org/~solar/patch_overlay/sys-apps/portage/ |
57 |
> |
58 |
> You may find some of those patches inspirational to your work. |
59 |
> |
60 |
> good luck. |
61 |
> |
62 |
|
63 |
I looked at the patches briefly. I think the most interesting piece was |
64 |
the treatment of config files based on PROTECTED_DIRS flag. |
65 |
|
66 |
Thanks for your help. |
67 |
|
68 |
> -- |
69 |
> Ned Ludd <solar@g.o> |
70 |
> Gentoo Linux |
71 |
> |
72 |
|
73 |
- Nimish <npac@××××××××××.com> |
74 |
|
75 |
|
76 |
-- |
77 |
gentoo-portage-dev@g.o mailing list |