Policy says that "small" files should be compressed, but does not define
small. The default blocksize seems like a good definition. What is the
default blocksize? 1k? 4k? Variable? I have heard all three answers.
I'm considering changing debhelper to compress doc files > 1k, which is
surely the sm
It appears something was wrong with the pipeline I wrote. Sorry for
all of the package errors sent to this list.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Li
> > (1) All pixmaps and bitmaps live in /usr/share/icons. End of story.
> > *NO* pixmaps or bitmaps will live in /usr/X11R6/include.
>
> This one gets my vote.
>
> I think it's a good idea in general, and it'll be trivial for me to alter
> my packages to suit, so I'm not too fussed about wha
On Tue, Nov 02, 1999 at 10:15:52AM +1100, Daniel James Patterson wrote:
> On Mon, Nov 01, 1999 at 01:43:03PM +, Julian Gilbey wrote:
> >
> > This is patently absurd: there is no need to have *three* locations of
> > pixmaps and three for bitmaps on our systems, in addition to a
>
> I agree.
>
Previously Julian Gilbey wrote:
> Well, maybe. They are, indeed, written as C include files, but that
> does not make them C include files: programs do not tend to say things
> like:
I've seen lots and lots of programs that do exactly that and I would be
unpleasantly surprised if they suddenly br
> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
Joey> Policy says that "small" files should be compressed, but does
Joey> not define small. The default blocksize seems like a good
Joey> definition. What is the default blocksize? 1k? 4k? Variable? I
Joey> have heard all three answers.
On Tue, Nov 02, 1999 at 02:19:26AM +0100, Laurent Martelli wrote:
> > "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
>
> Joey> Policy says that "small" files should be compressed, but does
> Joey> not define small. The default blocksize seems like a good
> Joey> definition. What is the
Laurent Martelli wrote:
> Shouldn't all programs that can display doc files handle compressed
> files natively ? Having to manually uncompress the file or use a
> special command that handles compressed files is unconvenient,
> especially for beginners who might even not be able to read those
> fil
Wichert Akkerman wrote:
> I've seen lots and lots of programs that do exactly that and I would be
> unpleasantly surprised if they suddenly broke.
Ditto.
Heck, I've even wrote some.
--
see shy jo
> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
Joey> Laurent Martelli wrote:
>> Shouldn't all programs that can display doc files handle
>> compressed files natively ? Having to manually uncompress the
>> file or use a special command that handles compressed files is
>> unconvenie
On Tue, 02 Nov 1999, Wichert Akkerman wrote:
> > Well, maybe. They are, indeed, written as C include files, but
> > that does not make them C include files: programs do not tend to
> > say things like:
> I've seen lots and lots of programs that do exactly that and I would
> be unpleasantly surpr
> *Parts*, fine, I have no problem with parts. I was just a little
> croggled by the example of trying to autogenerate *all* source
> dependencies for the debian-policy package.
The automatically generated parts will be only -dev packages for
shared libs.
> I think it may turn out to be more hai
> Previously Julian Gilbey wrote:
> > Well, maybe. They are, indeed, written as C include files, but that
> > does not make them C include files: programs do not tend to say things
> > like:
>
> I've seen lots and lots of programs that do exactly that and I would be
> unpleasantly surprised if th
> > > (1) All pixmaps and bitmaps live in /usr/share/icons. End of story.
> > > *NO* pixmaps or bitmaps will live in /usr/X11R6/include.
> >
> > This one gets my vote.
>
> I'd be careful. There are technical issues and established worldwide practice
> that we could be overlooking.
>
> I onl
On Mon 01 Nov 1999, Julian Gilbey wrote:
>
> This message is about bitmaps and pixmaps which are intended to be
> "public", that is, for use by more than just one program or small
> group of programs. Thus it would include an icon to be used by a
> window manager to represent an iconified xterm,
As previously discussed on -policy, I am announcing my intent to create
a new metapackage called `build-essential'. Its primary function is
to serve as the informal list of build-essential package referred to by
the forthcoming policy edition. It fulfills this mission in two ways:
* It will Dep
Hi all,
David Coe and I are pleased to announce the "Debian Spelling Dictionaries
and Tools Policy", as well as the new dictionaries-common package that will
provide the infrastructure to implement it. This work has been under
discussion since two weeks among maintainers of ispell related packag
> Fair enough. As someone then (almost) suggested, have
> /usr/X11R6/include/X11/{pix,bit}maps both be symlinks to
> /usr/share/icons and keep all icons there.
This is nice, but aren't you implying that all {pix,bit}maps are
icons?
> As previously discussed on -policy, I am announcing my intent to create
> a new metapackage called `build-essential'. Its primary function is
> to serve as the informal list of build-essential package referred to by
> the forthcoming policy edition. It fulfills this mission in two ways:
>
> *
Roman Hodek <[EMAIL PROTECTED]> writes:
> > *Parts*, fine, I have no problem with parts. I was just a little
> > croggled by the example of trying to autogenerate *all* source
> > dependencies for the debian-policy package.
> The automatically generated parts will be only -dev packages for
> shar
20 matches
Mail list logo
