[Nix-dev] What about introducing deprecated or such an attr name?

Marc Weber marco-oweber at gmx.de
Thu Nov 20 01:30:43 CET 2008


> What would be the semantics of such an attribute?  Should nix-env print a
> warning when you try to install a package with a deprecated attribute?  You
> could also put such information in the description attribute.
> 
> While on the subject, we could have an attribute that specifies that one package
> is a replacement of some other, removed package.  E.g. if we remove tetex, we
> could say in texlive something like
> 
>   meta = {
>     upgrades = ["tetex"];
>   };
> 
> and then if you do a nix-env -u \*, tetex would be upgraded to texlive
> automatically.
> 
> This could also be useful for handling package renames.  For instance, I want to
> rename MPlayer to mplayer, but that's not really supported right now.

Eelco: fantastic!
But if the executables are not named the same way you may miss the
update. So maybe it should tell you about this kind of upgrade?
But that's not that important.

I only thought about 
  if pkg.meta ? deprecated 
  then __trace "${pkg.name} is deprecated" pkg 
  else pkg
or such. But then I realized that I wouldn't read it.. (I didn't even
read that eval failed for half of today :-( )

If we are at it: Still I'd like to see the feature:

meta = {
  alsoInstall = [ pkg.foo ];
}

(eg pdfnub needs texLive to work, ...)
and if you've never used tex you won't know that kpsewhich is
provided by texLive..
Hard to say wether this should upgrade foo has already been installed.

Marc



More information about the nix-dev mailing list