1 |
-- Begin Newbie Rant |
2 |
|
3 |
First (as it is my first post), I'd like to say thanks to all the people |
4 |
who've made gentoo what it is today. I've used lots of linux distributions |
5 |
but Gentoo was the first to make me feel at home. So thanks for creating |
6 |
something I have, am and hope to continue enjoying. |
7 |
|
8 |
-- End Newbie Rant |
9 |
|
10 |
Perhaps I'm totally missing the point but.... |
11 |
|
12 |
On the large scale, there will be soon if not already a need to know |
13 |
when a package was released and/or what version of the distribution it |
14 |
first occurred in. In addition, making dependency information more |
15 |
accessible, up to date and more detailed would be helpful as well. These |
16 |
needs would be in addition to the general information portage currently |
17 |
stores about a packages (ie category, name, version, size, homepage, and |
18 |
description). |
19 |
|
20 |
For the large scale, a database would seem to be the logical choice for |
21 |
storing all this information. With a web or similarly easy interface to |
22 |
allow casual browsing and or administration. You'd want to have primary |
23 |
servers which would ideally feed mirrors who then in turn feed users. |
24 |
Though they could feed the end users as well. |
25 |
|
26 |
For the individual system, I think the DB idea is overkill but I like |
27 |
the plugin ability. Maybe a step similar to choosing your cron/syslog but |
28 |
instead you would be choosing your portage backend. |
29 |
|
30 |
One of the key strengths of Gentoo I see as an end user is that most/all |
31 |
of the files which determine how I can build/configure my system are |
32 |
directly editable. In practical terms, this openness has encouraged me to |
33 |
pro-actively attack problems rather than wait for fixes. Ultimately |
34 |
allowing me to feel a direct part of the Gentoo community, even if I'm |
35 |
only hacking my system. |
36 |
|
37 |
Now what if the portage on end user systems retained a XML text file |
38 |
format similar to the example below. This would give us the flexibility of |
39 |
text, as it is readable by the normal human, while at the same time |
40 |
machine friendly. The example below is just a quick idea how a ebuild file |
41 |
might look in an XML portage system. |
42 |
|
43 |
Example XML file for a package: |
44 |
|
45 |
<package> |
46 |
<name></name> |
47 |
<version></version> |
48 |
<size></size> |
49 |
<homepage></homepage> |
50 |
<license></license> |
51 |
<portage_release_date></portage_release_date> |
52 |
<slot></slot> |
53 |
<ebuild_comment></ebuild_comment> |
54 |
<description> |
55 |
<keywords></keywords> |
56 |
<abstract>one line info text</abstract> |
57 |
<full_text>full about text</full_text> |
58 |
<ebuild_comment></ebuild_comment> |
59 |
</description> |
60 |
<dependency> |
61 |
<name></name> |
62 |
<version></version> |
63 |
<mandatory>yes or no</mandatory> |
64 |
<reason>why it might be good to have this</reason> |
65 |
</dependency> |
66 |
<ebuild_commands> |
67 |
<ebuild_comment></ebuild_comment> |
68 |
<pkg_setup> |
69 |
<ebuild_comment></ebuild_comment> |
70 |
<commands></commands> |
71 |
</pkg_setup> |
72 |
<src_unpack></src_unpack> |
73 |
<src_compile></src_compile> |
74 |
<src_install></src_install> |
75 |
<pkg_preinst></pkg_preinst> |
76 |
<pkg_postinst></pkg_postinst> |
77 |
<pkg_prerm></pkg_prerm> |
78 |
<pkg_postrm></pkg_postrm> |
79 |
<pkg_config></pkg_config> |
80 |
</ebuild_commands> |
81 |
</package> |
82 |
|
83 |
The nice thing about XML is it could also be used with the plugin idea, |
84 |
allowing for a intermediate structured format for transfer between the |
85 |
gentoo servers/mirrors and the end user system. Backends are given the |
86 |
data in a format they can parse through without to much trouble and you |
87 |
could also export a ebuild out in a structured format perhaps allowing for |
88 |
remote submission of ebuilds. |
89 |
|
90 |
Now that I'm thinking about it you could have two XML package template |
91 |
versions, detailed and optimised versions. The detailed version would be |
92 |
as shown above containing absolutely everything about the ebuild. The |
93 |
optimised version would contain just minimum elements needed for the |
94 |
portage system. This would have the secondary effect of having optimised |
95 |
mirrors which only have those bare bones ebuild files.... |
96 |
|
97 |
I'm rambling so I'll end this. Thoughts? Flames? Expressive Grunts? |
98 |
|
99 |
|
100 |
-- |
101 |
Brian |
102 |
|
103 |
|
104 |
|
105 |
|
106 |
|
107 |
-- |
108 |
gentoo-dev@g.o mailing list |