Scratch Idea #2, it doesn't make sense.
For curiosities sake, how many packages actually have the same name, with or
without categories? The only one I have come across is git, which are in two
different categories and would have different tag clouds. The best solution
so far does seem to be by homepage, since it is already supported even
though not every package has one...
- Jonathan Dehan
On Sat, May 31, 2008 at 3:52 PM, Michael Croes <[EMAIL PROTECTED]> wrote:
>
>
> > Idea #1: Require the developer as a tag, or treat as something special
> > like a slot. This won't resolve all conflicts but if the same group
> > offers extremely similar products (names, tags) but there is a big
> > difference then you can slot them easily.
> > a/bunch/of/tags/dev/packagename-version:slot:repository
> > or
> > a/bunch/of/tags/packagename-version:slot:dev:repository
>
> sys/base/kernel/os/linux/kernel/vanilla-2.6.26-rc4:2.6:linus
> torvalds, ... ... ...:arbor ? It makes some sense, but then I think it
> would be better to stick to website instead of developer, even though
> not all software has to have it's own dedicated webspace.
>
> > Idea #2: Rethink slots, generating them on the fly. Expand
> > exndbaum to include a hidden package ID to resolve conflicts
> > internally, presenting the packages in different slots. What
> > happens when someone wants to install both 'identical'
> > packages? This is really just the same thing as --by-id except
> > the slot numbers basically come down to the number of options
> > the user has, not some seemingly random number. This kind of
> > leans towards a more interactive client though, so again its
> > not the best option.
>
> I think this has nothing to do with slots as they are anymore. Either
> way you are proposign that there still be some package ID ('hidden
> package ID'), then why hide it? I don't think using an ID is a good
> idea, but I surely don't think it's the worst idea. Your way of
> expending it to slots in some obscure way seems like a bad idea to me
> though.
>
> > Idea #3: I would love to see the tag cloud exported at the
> > filesystem level, with symlinks to where the exheres actually
> > reside. So arbor/packages/$PN-$PV.$EAPI would contain all the
> > packages, and $repo/tags/bunch/of/tags/symlink-to-exheres
> > would let you browse the tags like a filesystem. It could be
> > generated while reinstalling the cache. Another option would
> > be to put the tags in $tagdir/{all,arbor,x11,etc}. This could
> > be really neat, or really horrible. At the very least, api
> > hooks to get the entire tree would be nice, for third party
> > developers to do it with.
>
> I think you're right at one point in this paragraph: it could be
> horrible. I can see why someone would like this and I think it could be
> a great FUSE project, but I don't see any real use for the package
> manager.
> Regards,
>
> Michael Croes
>
>
>
>
> _______________________________________________
> Exherbo-dev mailing list
> [email protected]
> http://lists.exherbo.org/mailman/listinfo/exherbo-dev
>
_______________________________________________
Exherbo-dev mailing list
[email protected]
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
