[Nix-dev] Reorganization of the nixpkg file hierarchy

Nicolas Pierron nicolas.b.pierron at gmail.com
Mon Feb 9 08:52:53 CET 2009


On Sun, Feb 8, 2009 at 10:49, Marc Weber <marco-oweber at gmx.de> wrote:
>> In my opinion there will not be any redundancy for you if you want to
>> ignore pkgtags/ directory alongside pkgs. Those who want to use it would
>> find some - probably redundant - symlinks that will help them to
>> understand what in nixpkgs structure corresponds to things they expect.
>>
>
> So we could use a text file and put in the path instead equally well.
> I got it now.

So, If I understand well, we can choose to ahve multiple directory
hierarchies (in addition to/instead of) the current one.  Just based
on what I saw, when there is a directory hierarchy, people always
complained because they suffer from packages which could not fit into
any special directory.  As example, let's take a packages which
provides a client and a daemons, where should you put it ?

> But then we can use tags and we'll get the same result.
>
> Maybe we could just use
>
> meta = {
>  gentoo_location = " app-admin/http";
>  tags = [ "http" "daemons" ];
>  [..]
> }
>
> Then we could even automatically generate those symlinks or files or
> whatsoever ?
>
> Why do i prefer this? Less work to mantain.

On the other hand, you can just stop any package "segregation" by
using only one directory.  Then you can search for packages  (which is
the main purpose of directory hierarchy) by selecting tags that you
want to see.  In addition, tags gives you the ability to use logical
expressions over them, which corresponds to the traversal of dynamic
directory hierarchy (filters).

They are still some issues with tags. Usually putting everything into
one directory can slow down your search into the directory and some
file systems may only accept a limited number of files per directory.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron
- If you are doing something twice then you should try to do it once.



More information about the nix-dev mailing list