| 1 |
Why do this at a filesystem level? I may be missing the point, but why |
| 2 |
not just incorporate this into a seperate tool and keep a file to store |
| 3 |
all the comments and data. Or just include it as a comment in the |
| 4 |
.ebuilds and build a tool to search through these comment strings and |
| 5 |
write its own as u add categories? |
| 6 |
|
| 7 |
Joe Hardin |
| 8 |
|
| 9 |
On Thursday, Jun 5, 2003, at 00:47 America/Denver, Michael Kohl wrote: |
| 10 |
|
| 11 |
> Hi all! |
| 12 |
> |
| 13 |
> Following all the recent discussion about categories in the Portage |
| 14 |
> tree, having packages in several categories at once, defining key words |
| 15 |
> for packages to ease finding a similar package an idea came to my mind. |
| 16 |
> |
| 17 |
> Would it be possible to use filesystem attributes for Ebuilds (of |
| 18 |
> course |
| 19 |
> only if the FS supports this, maybe a local useflag can do the trick)? |
| 20 |
> This would allow users to build categories "on the fly" using a kind of |
| 21 |
> live query mechanism. |
| 22 |
> |
| 23 |
> People familiar with BeFS most probably know what I'm talking about, |
| 24 |
> for |
| 25 |
> anyone else just a little info: |
| 26 |
> |
| 27 |
> This would allow to store metadata in text form for each ebuild as a |
| 28 |
> filesystem attribute. Therefore your filesystem kind of acts like a |
| 29 |
> database. Using this mechanism you also could add your own attributes |
| 30 |
> (e.g. "try_this" for ebuilds you're interested in testing sometime) and |
| 31 |
> then list all ebuilds having this attribute. |
| 32 |
> |
| 33 |
> Also the setup part of an Ebuild could set an attribute like |
| 34 |
> "installed" |
| 35 |
> in pkg_postinst, so it would be even easier to find all the packages |
| 36 |
> installed on your system. Using live queries (e.g. in a nice GUI) this |
| 37 |
> list would change immediately after you emerged a new package. Also |
| 38 |
> finding applications similar to each other would be quite easy, as you |
| 39 |
> can store quite a lot of metadata (e.g. mp3, ogg, media, player, etc. |
| 40 |
> for the xmms ebuild). Sure this could be done in various other ways, |
| 41 |
> but |
| 42 |
> using FS attributes just sounds like a good way of doing it. |
| 43 |
> |
| 44 |
> Comments (especially about the various FS and their usefullnes for this |
| 45 |
> purpose), ideas, thoughts anyone? |
| 46 |
> |
| 47 |
> Michael |
| 48 |
> |
| 49 |
> P.S. Sorry, the thoughts in this mail aren't all that well organized or |
| 50 |
> explained, I'm not feeling to good today... |
| 51 |
> |
| 52 |
> -- |
| 53 |
> www.cargal.org |
| 54 |
> GnuPG-key-ID: 0x90CA09E3 |
| 55 |
> Jabber-ID: citizen428 [at] cargal [dot] org |
| 56 |
> Registered Linux User #278726 |
| 57 |
> <mime-attachment> |
| 58 |
|
| 59 |
|
| 60 |
-- |
| 61 |
gentoo-dev@g.o mailing list |
Archives