> 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

Reply via email to