Getting package build dependencies

2006-10-25 Thread Ross Boylan
I am interested in getting build-dependencies for a source package on
a system using aptitude.  In the past I've used apt-get build-dep, but
that was on systems managed with apt-get.  I think aptitude won't know
about apt-get's selections, and may toss the packages at the first
chance (or perhaps get confused in some other way).

Is this analysis correct?  If so, is there a good solution?

The two other routes I see are to use dpkg-checkbuilddeps (but then I
still need to get the output into aptitude) or to use one of the
autobuilders that work in a chroot (which seems kind of heavy weight).

Thanks.

Ross Boylan

cc's appreciated.

P.S. apt-get build-dep has always made me a bit uncomfortable, since I
presume it goes by the installed binary package.  If you want to build
some other version (e.g., system is testing but you want to build
unstable) the dependencies aren't necessarily quite right.  So I'd be
happy to discover an alternative.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Which packages will hold up the release?

2003-10-10 Thread Ross Boylan
There are some mathematical tools that might be useful in working with
some of these issues (I know them from models of social networks).

One can represent relations between packages as a matrix D.  The rows
and columns refer to packages, and the cell is 1 if a relation exists,
otherwise 0.  For example, D[i, j] is 1 if package i depends on
package j.

One can define a funny form of matrix multiplication, in which the
result can only be 0 or 1.
 Let D2 = D^2 = D*D 
Ordinary matrix multiplication says
D2[i, j] = sum_k D[i, k] * D[k, j]  (using pseudo-TeX notation)
The modified form is
D2[i, j] = or_k D[i, k] * D[k, j]  (in other words: 1 if any of the
combinations is 1)
equivalently this = max(1, sum_k D[i, k]* D[k, j])
So D captures all direct dependencies, and D^2 has all direct
dependencies and indirect dependencies of length 2 (usually D2
includes all of D, i.e., all direct relations, but if D[i, i] is not 1
that may not be so). 
D^infinity will have a stable limit, and expresses *all* direct and
indirect dependencies.

Since Björn already has a list of all indirect dependencies, I'm not
sure this contributes anything useful.  However, one can map a variety
of relations using this approach (depends on, conflicts with, is a
substitute for are some obvious ones), and then there are various tools to
look at all the relations together (they form an algebra), and there
are tools for separating individual packages into similar clusters
based on their patterns of relations.

It's also easy to make statements using this notation.  For example,
if D represents depends on (directly or indirectly) and C conflicts
with (direct or indirect), then we can say that if
D or C  0 (or is element by element, 0 is a 0 matrix)
a logically impossible set of relations has been specified (I think;
even if it's substantively wrong I hope you get the flavor).

I still have only a partial handle on all the substantive issues
involved in releasing packages, but throw this out on the chance it
might be useful.

More generally, it may be that taking the perspective of the overall
pattern of relations provides some value beyond looking at things
strictly from the perspective of a single package.

P.S. I'm not a Debian developer or a subscriber to this list, but
followed it on the web.  I've tried to fake my headers so it appears
properly in the thread.  I'm curious if there's a good way to do that.




Bug#62878: Screen display problems with terminals.

2003-06-29 Thread Ross Boylan
On Thu, Apr 03, 2003 at 04:43:31PM +0200, Bill Allombert wrote:
 Hello,
 
 It seems sthat changing the font have solved the problem
 so we can close this bug report ?
 
 Cheers,
I am very belatedly catching up with this question.  It doesn't seem
to me the bug should be closed.

It appears that things work for some combinations of terminal
programs, font selections, and TERM variable settings, but not others.

It seems to me it should work for all, or it should be better
documented why it doesn't.

I can't fully check this behavior because I am having other, more
serious font problems.  If I select Lucida-Typewriter font in my KDE
Konsole now, nothing at all shows up.  However, if I set the font to
medium in the Konsole settings, things work OK with TERM=xterm (the
default) but not TERM=linux.  Same for an xterm.

It *might* be appropriate to close this if the defaults for all
relevant packages put in sensible values and alternatives, so the
problem does not arise.  I'm not sure what all relevant packages
are, since some of this stuff might go in general start up files.