ometimes allowed is even worse than having them always
allowed, so it makes me support the proposal more strongly :)
Richard Braakman
e name), so using one more line to add the short
description won't hurt anything. And writing good descriptions
is a lot easier if you can assume the long description will be
read in the context provided by the package name and the short
description.
Richard Braakman
do.
"should include" really means it's a bug if the package doesn't do that.
The difference between "should" and "must" is that "must" is
release-critical.
Richard Braakman
editor in a graphical environment. I think it's pretty
common to want different editors in text and graphic modes.
Richard Braakman
can give you the perspective of an ftpmaster a couple of years ago:
such batch bugreports were basically useless without input from the
maintainers involved. If we wanted a big list of priority conflicts,
we had the scripts to generate one.
--
Richard Braakman
Furthermore, I believe that SCO should be destroyed.
On Thu, May 01, 2003 at 10:18:07PM +0200, Bill Allombert wrote:
> I remembered to have read something to that effect when packaging
> my first shared library, but I cannot find it today.
Indeed. I thought we've had this policy since the libc5 -> libc6
conversion. Did we reg
ipting language currently used to implement it.
>
> but I can easily be persuaded otherwise.
I'd like a "just" or "simply" before the "denotes", otherwise
we'll get cheeky people arguing that naming a perl script "doit.sh"
is just fine :)
Richard Braakman
On Thu, Mar 20, 2003 at 11:10:58PM +0100, Bill Allombert wrote:
> Why? because they support building packages as root when
> dh_testroot can solve a lot of headache ?
What does dh_testroot solve in the clean target? Seriously.
I've never understood why people put it in.
Richard Braakman
, and it does no harm because the binary target
_will_ need root at some point. (Also, the binary target is usualy
not incremental, so restarting it takes longer than restarting a clean.)
Richard Braakman
_not_ put dh_testroot in the clean target. It serves no purpose.
If you need root to clean then you'll know soon enough.
Richard Braakman
ailure conditions.
Richard Braakman
libssl0.9.7-dev
libssl0.9.6-dev Conflicts with libssl0.9.7-dev
libbreakseverything's build-dependencies would be uninstallable.
I think it would avoid the problem, but it would be a major headache
to deal with in practice. It would be as bad as tcl4.* used to be,
and I'm glad we left THAT behind.
Richard Braakman
I'm
> missing something obvious.
The main reason is to be able to compile binaries that will run on
a variety of systems. I know I was annoyed at Solaris for not including
static versions of the socket libraries, for example, and I wouldn't
like to inflict a similar annoyance on someone else.
Richard Braakman
de much more clear by eliminating
the parentheses completely:
"However, programs that require dotfiles in order to operate sensibly
are a bad thing, unless they create the dotfiles themselves automatically."
This way the qualifier does not interrupt the main statement.
Richard Braakman
l, and all
filename arguments on the command line should be encoded in UTF-8.
Umm, except that the shell doesn't know which arguments are filenames.
How should this be done?
Richard Braakman
lopers, not *against* them. How are you planning
to impose an i18n policy on people who have been excluded from
discussing it?
Richard Braakman
We could put them in both locations for a while.
Richard Braakman
be included in the
> + package.
> +
I would also do s/implies/means/ here.
--
Richard Braakman
"I sense a disturbance in the force"
"As though millions of voices cried out, and ran apt-get."
(Anthony Towns about the Debian 3.0 release)
needlessly difficult.
For what it's worth, I have never had a problem with debugging optimized
code. The line numbers sometimes jump around a bit, but always in a
predictable way.
--
Richard Braakman
"I sense a disturbance in the force"
"As though millions of voices cried out, and
ed editor. Note that sensible-editor
itself is in debianutils.
The virtual-packages changelog shows that an "editor" entry was actually
added and then removed in 1996.
Richard Braakman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
eate a directory in `/usr/local' for local additions to a
package, you should ensure that settings in `/usr/local' take
precedence over the equivalents in `/usr'.
[...]
This is the general policy for /usr/local, and I see no reason why it
shouldn't apply to /usr/local/bi
the default /bin/sh and you know it". :-)
Richard Braakman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
se same speed freaks are
likely to be using ash, which has both "type" and "command -v".
I once again recommend a deathmatch between ash and zsh fans. Let
the best shell win.
Richard Braakman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
you manage to miss sed's y command?
#!/bin/sh
sed "y/$1/$2/"
Supporting all of tr's options is left as an exercise for the reader :-)
Richard Braakman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
would compensate
for that.
Richard Braakman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
All languages I can
think of that use '_' as a separator do so because '-' is already taken
as an operator. I guess a statistical analysis of unix filenames might
show which separator is the most popular :-)
Richard Braakman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Tue, Jan 29, 2002 at 06:15:55PM -0500, Jim Penny wrote:
> On Tue, Jan 29, 2002 at 02:20:31PM -0800, ike jude wrote:
> > OKAY PRINCE
> > [EMAIL PROTECTED]
... and one of my rules of thumb is not to do business with people who
can't spell their own names :)
Richerd Braakman
ke you agree with the spirit of Anthony Towns's proposal?
Indeed. I hadn't realized that, until I re-read the mail where he
explained it again. Yes, there would be only minor differences
between his proposal and what I had in mind.
--
Richard Braakman
Will write free software for money.
ven small extracts from the
manual it is bound to, and it might migrate to smaller manuals.
I don't think the size of the manual it originally accompanies is
all that relevant.
[I've cut down the crossposts to "just" debian-legal and debian-policy.]
--
Richard Braakman
Will write free software for money.
See http://www.xs4all.nl/~dark/resume.html
and less so in
an installer context. That's why I think the list should be documented.
For what it's worth, I think this would be a fine addition to policy,
provided that the details work out.
--
Richard Braakman
Will write free software for money.
See http://www.xs4all.nl/~dark/resume.html
On Mon, Jul 30, 2001 at 06:43:44PM -0400, Raul Miller wrote:
> On Tue, Jul 31, 2001 at 12:25:34AM +0300, Richard Braakman wrote:
> > How much of a C reference is it?
>
> It's gcc specific, is it not?
Yes but gcc has a shared backend for multiple languages :-) It
wouldn&#
ically because -fpic does not work
right on all architectures. I think that trying to prescribe different
flags for different architectures will cause insanity. Remember, there's
only one source package.
--
Richard Braakman
Will write free software for money.
See http://www.xs4all.nl/~dark/resume.html
I added the last sentence to make clear what happens if the assumptions
of the first paragraph are broken, but I'm not happy with the wording.
The reason for explicitly following the conventions for a development
package is that it makes it easy to add a shared version later.
> Richard,
ed with "dd."
I prefer semantical correctness :)
--
Richard Braakman
Will write free software for money.
See http://www.xs4all.nl/~dark/resume.html
nst your sanity.
Richard Braakman
eme in mind), and it would mean changing the soname
for every upstream release. For some libraries that's just not
worth it.
I also present publib-dev as an example of a library which currently
provides only a static version, but I will let its maintainer speak
for himself :-)
--
Richard
stat() functions. This has caused breakage in bash and libreadline
in the past; I can look up the bug number if you're interested.
--
Richard Braakman
Looking for a job writing free software
http://www.xs4all.nl/~dark/resume.html
ask printing?
Hmm... all along I've assumed that the task selection process will
at some point pull in all the dependencies of the selected tasks.
Is this the case?
Richard Braakman
On Wed, May 16, 2001 at 08:30:50PM -0600, John Galt wrote:
> On Wed, 16 May 2001, Richard Braakman wrote:
> >It also doesn't require more than the name and the date, and it doesn't
> >forbid you from removing the notices for p
wrote Richard Stallman about this, when I heard he was working
on GPLv3. He said he'd think about it. Since there is no GPLv3 yet,
I presume he's still thinking :-)
Richard Braakman
hat if the plugins are not relocatable, their
code pages will not be shared between processes that use them.
That would be wasteful.
Richard Braakman
dy will try to make their plugins unstripped in the
> meantime.
There are already plugins that are not compiled with -fPIC, though.
(megahal and wine have some on my system.)
Richard Braakman
ect me if plugins are not
normally relocatable.)
Also, stripping with --strip-unneeded still seems like a good idea.
Richard Braakman
What kinds of bugs? The criterion I used for info-level tags was that
they were not bugs, just things a maintainer might want to know about
the package.
Richard Braakman
n though this is optional, this is still a good idea. [1]
I interpret this as "Please do this if it's convenient, but don't
worry about it if it's not".
Richard Braakman
aluable neurons that could be used to think
up better ways to write maintainer scripts.
Richard Braakman
intian is ready for it now, but if the archive scripts use
it then they should have a specific list of Lintian tags that are
grounds for rejection.
Richard Braakman
MAY simply means it's
optional, it doesn't have to be a good idea. And SHOULD is stronger
than a recommendation, it means you have to do this unless there's
a good reason not to.
Richard Braakman
On Fri, Mar 30, 2001 at 10:50:36AM -0600, Taral wrote:
> On Fri, Mar 30, 2001 at 07:07:19PM +0300, Richard Braakman wrote:
> > On Thu, Mar 29, 2001 at 07:48:32AM -0600, Taral wrote:
> > > which is really a system dependent thing. Those builders who want
> > > paralle
he proposal in #88029.
If that passes, there's no guarantee that debian/rules will accept
options at all.
Richard Braakman
s
below and the list of fields for the particular file.
This seems a bit awkward to do, reading three things at once while
writing a control file, and it gets pretty boring after the Nth
file :-)
Richard Braakman
only use it from a script, then you can put the full pathname there.
Richard Braakman
he only languages available for maintainer scripts
are shell and perl, because those are the Essential interpreters.
(I guess awk might work because an Essential package depends on it,
but I wouldn't want to rely on that without verification.)
Richard Braakman
I see it policy is there to give somebody the right of filing a bug
> report.
I strongly disagree with that view. I'm not on this list to help make
a sharper stick.
Richard Braakman
d be useful. It's something a maintainer might
not think of when writing a rules file. And I think it should go in
policy. Surely it is our policy to have documentation point to the
correct files?
Richard Braakman
in Lintian and in users' minds.
(Compare with libfakeroot, for example.)
Richard Braakman
prefer not to get one misguided bugreport after
another (not to mention Lintian warnings) about them not having
Build-Depends.
So please keep this in mind when formulating a new policy.
Richard Braakman
guessing are mistakes. I think that
> > division is still useful.
> >
>
> no, it tries to do this based on 2.x level MUST/SHOULD and the authors beliefs
> of severity. Has nothing to do with the sureness of the test.
When did this change, then? Christian and I designed it the way Anthony
described it.
Richard Braakman
x27;s guide :-)
(This was when the issue of the proper way to write a daemon came up.)
Still, I see nothing wrong with discouraging specific practices in
policy.
Richard Braakman
On Wed, Oct 18, 2000 at 01:05:28PM -0700, Chris Waters wrote:
>
> ~ $ grep-available -P roxen -sPackage|wc -l
>70
I think this is a different problem. There's no reason for every little
Roxen module to be a separate package.
Richard Braakman
n". There are bound
to be some specialized ones, such as task-klingon-dictionary-tools.
Richard Braakman
allow it in potato?
Because there's always something that breaks anyway. "Why not" is never
a good enough reason for changing frozen. And at this point, the question
is, what problem will this fix that would otherwise delay the release?
Richard Braakman
even legal?).
No, it will work. A versioned conflict can not match an unversioned
virtual package, so they will not conflict.
--
Richard Braakman
y* documentation, then there's not much
point in packaging it -- only people who have source code will be
able to use it.
Richard Braakman
inly informative;
I don't second-guess rejections unless the maintainer moves them back
to Incoming. (And in that case, I leave the package to a different
archive maintainer).
Richard Braakman
On Thu, Jan 13, 2000 at 12:01:33AM +, Ian Jackson wrote:
> Richard Braakman writes ("Re: policy summary"):
> > On Sun, Jan 09, 2000 at 09:38:17PM +, Matthew Vernon wrote:
> > > OTOH, new packages with lintian errors tend to get rejected - it would
> >
ightly these days. Writing a manpage for the program takes a bit of
thought and research, and is useful to boot. If a maintainer isn't
prepared to do that much for the package, then I say he has no business
packaging it.
Richard Braakman
> Should a mass bug report be filed against
> these (ls -l /usr/doc/ | grep ^d | awk ' { printf "%s ", $9 }
> ') packages?
No.
Richard Braakman
guess it's re-hashing time :) The point of this proposal was
that the presence of an "undocumented" manpage *doesn't* provide
that information, it only pretends to. There is little correlation
between "undocumented" links and "missing manpage" bugreports.
Richard Braakman
On Tue, Dec 14, 1999 at 12:08:44PM -0800, Joey Hess wrote:
> Richard Braakman wrote:
> > packages in main cannot _depend_ on non-main packages. They can
> > > however suggest and recommend them.
> >
> > Incorrect. Policy section 2.1.2 is explicit about this:
nd another place for packages that are patent-encumbered
in weird ways, if any show up. "non-free" will fit the bill in most
cases, I think.
Richard Braakman
all of non-US/main is free for use and distribution inside
the US. Putting GIF-creating packages in there would change that.
I think we need some kind of map of which packages should go where,
and what kinds of subdistributions we want.
Richard Braakman
are not compliant with the DFSG.
This will put all GIF-creating packages in main. Is that what we want?
Richard Braakman
I've been gone a week; this mail is a kind of summary reply, where I
pull together a number of threads.
Raul Miller wrote:
> On Sat, Aug 28, 1999 at 12:50:57PM +0200, Richard Braakman wrote:
> > That would be awful. Having to wait while something is rubberstamped,
> > j
arn something from it.
If the Technical Committee wants to be involved, then I suggest it
should simply confirm the adoption of the Policy Manual as Debian's
policy for package maintenance, possibly reserving the right to make
specific exeptions.
Richard Braakman
an the previous two releases as well :-)
Chris Waters wrote:
> Richard Braakman <[EMAIL PROTECTED]> writes:
>
> > That last sentence is an error. When all packages have moved to
> > /usr/share/doc, we can drop the symlink handling code from the
> > postinst and pre
e, but the essense
of Debian is much more in the vibrantly alive "unstable" than in
what we end up putting on CDs.
Richard Braakman
n't changed since then). It's on thousands of CDs,
after all, and we archive it on archive.debian.org.
Richard Braakman
Mike Goldman wrote:
> Therefore, I formally object to this proposal.
You have given reasons for not liking the proposal, but no reasons for
it being unviable. I think a formal objection is far too strong.
Richard Braakman
y in the architecture specifier. We may want something
like [i386 m68k sparc] (for example, and altgcc dependency), and perhaps
even [!hurd-i386], and it will still look good.
Richard Braakman
Anthony Towns wrote:
> As such, perhaps this should be reassigned as a wishlist bug against
> ftp.debian.org and apt?
Perhaps, but it is not likely to be implemented unless someone supplies
patches.
Richard Braakman
Joey Hess wrote:
> Richard Braakman wrote:
> > Joey Hess wrote:
> >
> > > But when they do, they discover they can no longer read alien's man
> > > page, becuase their old man browser doesn't grok
> > > /usr/share/man. What to do?
> >
>
which can then list further
dependencies.
Also, there's finally a proposal in the works for describing source
dependencies in a formal way. Let's not do it in two different ways.
Richard Braakman
Joey Hess wrote:
> But when they do, they discover they can no longer read alien's man
> page, becuase their old man browser doesn't grok
> /usr/share/man. What to do?
They can modify /etc/manpath.config to include /usr/share/man.
Richard Braakman
onflicts of the installed
> lib and the built lib.
Definitely a bug in ruby's build environment... imagine these :-)
gcc => binutils, !gcc
perl => !perl
> I think at least the cases of bash, plplot, and rpm are no bugs.
I think they are, for the reasons I've given above.
Richard Braakman
istant (<< 0.93) | debassistant (>> 0.93)
Is there any case where one would want a Build-Conflicts? Allowing
them will complicate all the code that deals with build dependencies,
whether they are used or not.
Richard Braakman
I think it's really nice that Debian has *all* configuration info in
the /etc directory, with no worries about other places to look. That
was one of the qualities that attracted me to it when I joined.
Richard Braakman
ng in dpkg's way. Examples of this going wrong are pretty complex
for the postinst, but for the prerm it's easy: each package must remove
only its own link.
Richard Braakman
Peter S Galbraith wrote:
> Don't use absolute links.
> >From policy version 2.5.0.0:
>
> 4.5. Symbolic links
> ---
>
> In general, symbolic links within a toplevel directory should be
> relative, and symbolic links pointing from one toplevel directory into
> another
ln -s /usr/share/doc/$package /usr/doc/$package
fi
fi
One problem remains: There is no $package variable available when the
maintainer scripts are run. The package name will have to be hardcoded
in the scripts, and for multi-binary packages that will be rather more
work than is advertised.
Richard Braakman
Manoj Srivastava wrote:
> Hi,
> >>"Richard" == Richard Braakman <[EMAIL PROTECTED]> writes:
>
> Richard> The best thing to do is probably to make sure that /usr/doc/ and
> Richard> /usr/share/doc end up on the same filesystem, but in separate
> Ric
s
developers).
Symlinking /usr/doc directly to /usr/share/doc is likely to break
things, though, since dpkg will be moving files from one to the other
without realizing that they are the same directory.
Richard Braakman
ution. I'm glad we're finally just doing it.
Richard Braakman
subsections, actually. The non-us packages are still in one directory
per section, and many just say "non-US" in their Section header.
Richard Braakman
joost witteveen wrote:
> forcetree
> Apps/Sound
> endforcetree
Is it also possible to specify that a menu (such as Apps) must have only
submenus? Mixed menus seem cluttered and I find them hard to use.
Richard Braakman
Wichert Akkerman wrote:
> Previously Julian Gilbey wrote:
> > I second this proposal.
>
> Please don't. As Ian Jackson once said: things like this should
> not be part of policy, but part os a set of coding guidelines.
The one that Manoj volunteered to maintain? ;-)
Richard Braakman
wtools, kbd, and nethack still install files into /etc/rc.boot.
>
> I believe it to be true in *potato* (but you are right about these
> packages in slink).
I am also right about these packages in potato.
Since console-tools and kbd were fixed this week, the current list is:
cnews, fidogate, gnomehack, gom, hwtools, and nethack
Richard Braakman
ato still use /etc/rc.boot, so this will not
> cause anything except policy to change. )
This is not actually true. cnews, console-tools, fidogate, gnomehack,
gom, hwtools, kbd, and nethack still install files into /etc/rc.boot.
Richard Braakman
ay be distributed, but
> they must be clearly indicated as not being the official Debian
> Policy."
But the GPL already required that modified versions be clearly marked.
Please see clause 2a.
Richard Braakman
text can turn up all kinds of
snags. It's like waiting for a package to be installed in the archive.
Richard Braakman
1 - 100 of 153 matches
Mail list logo
