[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: post-release package update policy

I'm not sure what's wrong with having an evolving system called Debian.  
There are many ways to install even Debian, so the ideal of a "fixed system" is
a little shaky.

Brian White, author of dftp, has mentioned to me that it there is no easy way
to deduce exactly what version of a certain Debian package P has actually been
installed when dselect/dpkg logs indicate that P is installed.  If true, this
is IMO an impediment to improving his dftp program and one day integrating it
with dselect itself.

If that information is/were available, it would be trivial to have a script
called debian-version (or uname-debian or debian-status or an option to dpkg)
that would give the Debian-versions of all installed packages.  In the style of
Emacs's `*-submit-bug-report', the output of this could be regularly included
in bug reports and requests for help.  Would this not allieviate the complaints
about an evolving release?

I will generally want to upload the latest version of any new package I use as
soon as it comes out.  There are two kinds of new packages I may NOT want to
upload, and I want to be able to identify them: 1) new packages which are
"experimental," that is, fails to meet a certain confidence level about causing
problems and exhibiting bugs that weren't there in the previous release; and 2)
new packages which require significant reconfiguration, that is, which are not
upwardly compatible (is that the right term?).  It seems to me that the Linux
kernel is released with a plan like this.

I want both these other types of packages to be available, but I want them
distinguished from the drop-in replacements and enhancements and expansions
that, I think, compose the majority of new package releases, and which I see
no reason to freeze at some random moment -- that's what CD's are for.

Reply to: