On Thu, 15 May 2008, Ondrej Certik wrote:
On Wed, May 7, 2008 at 10:16 PM, Timothy G Abbott [EMAIL PROTECTED] wrote:
That's probably a good plan, especially since the sandbox is apparently
going to be eliminated eventually (and it sounds like arpack and delaunay
are on the list of things
Yes, I realize there is not much time left. I'm also quite busy for the
next week or two, after which point I should have time to work on this
again. The precise release timeline is very helpful.
I won't be able to reasonably maintain this much software in Debian in the
long term, but I
You can make packages to do configuration, but there are tricky issues
involved in making sure that the right thing happens when the packages
you're configuring are upgraded.
At MIT, we wrote a system of CDBS modules that automates a lot of the work
involved in making configuration packages.
the python-scipy maintainers a note and see what they think.
-Tim Abbott
On Wed, 7 May 2008, Riku Voipio wrote:
On Tue, May 06, 2008 at 02:44:04AM -0400, Timothy G Abbott wrote:
Packages with no problems worse than missing man pages:
python-arpack (from the scipy sandbox)
python-delaunay
on the relevant bug
report. Thanks for pointing it out.
-Tim Abbott
On Tue, 6 May 2008, Bernhard R. Link wrote:
* Timothy G Abbott [EMAIL PROTECTED] [080506 08:47]:
singular [no soname]
Oh, nice to see that the omalloc license issue is finally solved.
The debian/copyright
I've been working on packaging for Debian SAGE (http://sagemath.org), a
large free mathematics software conglomeration that is competing with
proprietary mathematical software systems such as Mathematica, Matlab,
Maple, and Magma (Debian bug #455292).
This has been a rather large effort
On Tue, 6 May 2008, Kevin B. McCarty wrote:
I was going to suggest setting up an Alioth project, but on closer look
I see that the Sage Wiki page mentions that you don't want to use alioth
just yet.
Well, that text was written in November, and I think it was a good choice
at the time. But
Discussion on the technical details of using dpkg-divert for configuration
seems to have died down. My basic summary of the discussion is (A) any
system attempting to configure site defaults requires use of dpkg-divert
on conffiles[1], and probably should use dpkg-divert on all configuration
On Thu, 28 Feb 2008, Ian Jackson wrote:
Timothy G Abbott writes (Re: Debian Configuration Packaging System):
So, our goal is to provide our users with the same opportunities to
override our configuration defaults as they would have had if Debian had
been providing them instead. Using
On Tue, 26 Feb 2008, Frank K??ster wrote:
[...]
3) Scripts that are not marked as conffiles but which cannot be
configured in any way other than by modifying the script.
If those scripts live below /etc, they definitely should be marked as
conffiles. If they live elsewhere, no package should
On Tue, 26 Feb 2008, Ian Jackson wrote:
Tim Abbott writes (Re: Debian Configuration Packaging System):
applying dpkg-divert to configuration files.
Yikes.
At the moment, there are no choices for doing site configuration that are
general enough to change arbitrary configuration options
On Wed, 27 Feb 2008, Ian Jackson wrote:
Timothy G Abbott writes (Re: Debian Configuration Packaging System):
All of the important problems with our dpkg-divert based configuration
package system that have been discussed in this forum are problems for any
configuration mechanism other than
On Mon, 25 Feb 2008, Frank K??ster wrote:
Uh, you can dpkg-divert conffiles, but not generally configuration files, since
many won't even be known to dpkg. I must admit I'm a bit sceptical about a
proposal on configuration, written by someone who lets this important
distinction slip by...
Anders Kaseorg and I created a system of CDBS modules (which we've
tentatively packaged as the config-package-dev package) for creating
Debian configuration packages. By configuration packages, we mean
packages that configure an existing Debian system by applying dpkg-divert
to configuration
14 matches
Mail list logo
