[Nix-dev] Re: Is Emacs 22 still needed?

[Karn Kallio]

> Excerpts from ludo's message of Thu Aug 26 17:27:25 +0200 2010:
> > Hello!
> > 
> > Peter Simons <simons at cryp.to> writes:
> > > is anyone aware of a reason why we should week Emacs 22 in nixpkgs?
> > 
> > Someone could need it, e.g., because of some incompatibility or because
> > some Emacs mode hasn’t been upgraded to 23.  That’s arguably becoming
> > less and less likely, but who knows.
> > 
> > > As far as I can tell, the package is unused;
> > 
> > But you can’t actually tell.  :-)
> > 
> > > version 23 has been the default for quite a while now. To simplify
> > > matters, I'd like to remove the old version.
> > 
> > I don’t use 22 but I wonder to what extent keeping it is a burden.
> > What do you think?
> 
> I think we should not keep things just because it's no burden.
> Because everything is a burden in some way which does exist.
> 
> I think we should have a clear vision what nixpkgs is about.
> We should know about its identity.
> 
> If we think about nixpkgs serving people we don't know - and which don't
> talk to us - we may ignore them. (IMHO) - or we should try to find a way
> to make them talk to us: Eg by providing a command:
> nixpks-tell-about-my-packages-in-store-cause-im-still-using-them.
> 
> A simple way to manage this would be a maintainer adding
> # don't think anybody is still using this package
> # I propose removing it 2010-12.
> 
> and sending a mail to the mailinglist.
> 
> Someone who relies on a package has a chance to reply then - and we
> don't end up maintaining packages which are superseded (eg by emacs-23).
> 
> Maybe we can even create a Wiki page titled
> "packages marked for removal".
> 
> Until now the way to do it was "remove and see whether someone yells"
> 
> Happened to me with php-5.3 - ok, it was also a style issue I didn't
> share.
> 
> It doesn't matter what happened in the past. It matters how we want to
> cope with this situation (which will occur many times) in the future.
> 
> So talk about how you'd like to be notified about package removals - so
> that you have time to say "I'm still using it".
> 
> Maybe we can put a policy like info text on the wiki later.
> 
> I'm reading the mailinglist. So for me asking on the ml would be enough.
> 
> Marc Weber

Emacs 22 is not needed by me.

The emacs question prompted some more thoughts ...

If we apply a sort of functional model to Nixpkgs itself, then it should not 
be possible to alter Nixpkgs by removing ( or adding, for that matter ) 
expressions.  Various ( immutable ) versions of Nixpkgs could then be 
maintained, with more recent versions holding more recent versions of 
expressions.  So emacs23 would be found only in the last few versions of 
Nixpkgs.

Perhaps a possible migration of Nixpkgs to another version control system 
would be a good moment to introduce "functional Nixpkgs", implementing the 
versions or generations of Nixpkgs as branches in the VCS.

Then anyone wanting an old expression ( emacs22 say ) could get it from an old 
generation of Nixpkgs.  Maybe something like a --pkgs-generation flag could 
tell nix-env and friends which version of Nixpkgs to use. 

With respect to garbage collection, the various generations of Nixpkgs could 
never be reclaimed due to the impossibility of knowing whether somebody would 
still be using them.  But maybe that would not be a problem with an 
implementaion based on a DVCS ... darcs, git, monotone, mercurial and so on 
all seem capable of maintaining a great deal of versions/branches of code 
bases.

Something like this is currently possible using subversion revision numbers as 
version identifiers, the only new thing in the "functional Nixpkgs" would be 
identifying "official" or "release" versions that were internally consistent.  
At the moment a particular Subversion revision number can refer to a Nixpkgs 
with evaluation errors or failing/broken builds.  So this would be principally 
a social or user interface change rather than a technical one.

Of course maintaining "blessed" versions of Nixpkgs implies the need for 
somebody to do the work of making and maintaining them ...