err, does this break the use of tasks with apt-get later on? I've
found it very useful to do (for example) "apt-get install task-x-window-system"
after getting a machine otherwise working (in particular, that's the
easy way to go to xf4 - install 2.2, then point to testing, then
apt-get install ta
Yes, The X11 config used to use it (still does, upstream) but it's
wrong that it did so (anything compiled that way broke horribly when
the libc5 libs got moved to the compat dir...)
> You are arguing for an atomic kernel operation. Is that really fair?
No, actually, I'm simply pointing out that saying "there would be no
possibilities for errors" was, as it stood, incorrect -- and your
argument depended on it being correct. It's a minor point, but I
thought I made that clea
> Unfortunately, my hopes have been dashed. I now realize that dpkg has
> only ever aspired to be "throw away code", so I should look elsewhere
Tsk, tsk. Not all custom applications are throwaway, even though the
"unix philosophy" might indicate that. Sometimes, as in this case,
they actually
Just to make it clear, not to keep pounding, but:
>Again, with the proposed system, this is easy - just install an upgraded
>src-orig-*.deb file.
I don't think I'll find any src-orig-*.deb files on prep. My point
was that I can take the .tar.gz files that I *do* find everywhere and
just use them
>Using dpkg this way is great for my proposed source packages, but it is
>also useful for any Debian package you might want to install in
>user space only.
Clever -- but an amazing kludge :-) Remember that it's ok for this to
be hackish for "installing debian packages in user space" because
that
I would like to add another benefit of Source-Depends: which I
consider important simply because it would have saved me significant
grief in the past: it lets a package maintainer pass along important
details to whoever manages the package next, so they don't have to
find out by trial and error. T
> You are forgetting that when you run dpkg-source -x, it copies a
> .orig.tar.gz file to your directory. So there is no difference in
> disk space used.
Disk space wasn't the point -- just actual steps of work involved (and
by steps I mean "points of failure" as well, ie. more automation does
*
> We already do, when you run dpkg-source --build, it makes a .orig.tar.gz
> file, a .diff.gz file, and a .dsc file.
Actually (though I admit hello-source.deb is a cool hack, it's still a
hack -- and debian has mostly gained it's superiority from getting the
*details* right; that's *why* dpkg is
Detail: I think "installing" sources is fundamentally wrong. This is
partly aesthetic, but that is derived from large scale systems
experience -- there's the system, and there are the users, and
building packages is a *user* function, not a *system* function. (The
required use of /usr/src/linux f
I hate to say it, but this is one nice thing about rpm spec files: you
just list Source: ftp://host/path/foo.tar.gz and if foo.tar.gz is in
the local SOURCES dir, it uses it -- and handles multiple Source:
lines. (It's trivial, but it's useful...)
In particular, I'd find something like that usefu
> And of coure, we have the TrueType and Postscript fonts, each of which
> has their own font servers. (I think)
I have no reason to believe that...
> So how DO I get the fonts in xfnt100 to be recognized?
your /etc/X11/XF86Config should have
Section "Files"
RgbPath"/usr/X11R6/lib/X11/r
:-) The trick is that xset isn't a general solution, though it's fine
for one user. (Not good enough for xnest, or xfs, for example.)
Until I read some of the points on this thread, I also thought that
just stuffing them in directories was enough...
Ok, at this point I'm convinced that there's a need for tools to
manipulate font path related stuff. I'll see what I can come up with.
(I'd forgotten about the emacs20 font pack, that's a good one too.) I
still haven't found out what the actual xfs config problem is (when I
developed the gzip-fon
> No, my package `xfntil2' deals with X fonts (it's X fonts package :-).
In that case, do exactly what xfnt100 and the like do, as far as
rerunning mkfontdir. If you want to avoid dealing with getting the X
server to find the fonts (as for a game with only a few of them) I'd
recommend "cheating
umm, there doesn't need to be font "policy" -- X deals with X fonts,
nothing else does, that's all there is to it, right?
As for xfs not recognizing fonts in xfnt100 -- if you've spent enough
time with the documentation to figure out that it's really not your
fault, presumably you should file a bu
16 matches
Mail list logo
