Hi,
I broadly agree with what you said.
Russ Allbery writes:
> 2. Do nothing further before January 6th. It's still the holidays, and
>subsequent steps are going to require some discussion, and I think it's
>worth taking a breath.
This, particularly.
>My thought process here is t
tags 765499 +patch
quit
Hi,
Here's a patch to document the 32-bit nature of UIDs, in line with Ben's
suggestion (which seems sound to me). I've added a note to the effect
that useradd won't use the higher-numbered UIDs, which seems sensible as
a) that requires no changes to useradd b) there are s
Hi,
Ben Harris writes:
> Policy 9.2.2 lists ranges of UIDs and GIDs and what they're used for
> in Debian. However, it limits itself to UIDs and GIDs below 65536.
> As far as I can tell, on a modern Debian GNU/Linux i386 system UIDs
> and GIDs are unsigned 32-bit integers. In consequence, Poli
Sean 'Shaleh' Perry writes:
> Anyone have comments on the idea that the only packages we should release are
> ones that have a maintainer, not Debian QA?
How about asking the QA team? I think that "packages maintained by the
QA team" is a poor criterion for getting software. They shouldn't
delay
> This requires dpkg changes, and doesn't seem like it's particularly
No it doesn't - currently I could make /usr/share/doc point at
/dev/null, and dpkg wouldn't mind. Problem is, some packages look at
files stored in /usr/share/doc, and so would break.
Matthew
--
"At least you know where you
Jonathan Walther writes:
> -BEGIN PGP SIGNED MESSAGE-
>
> So what will it take to get the FHS ammended to add libexec in? It
> seems like a major oversight.
Why? Please justify this.
Matthew
--
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a padd
Jonathan Walther writes:
> -BEGIN PGP SIGNED MESSAGE-
>
> I think its time we created /usr/libexec as all real Unixes do instead of
> an endless succession of /usr/lib/program-foo directories.
Why?
Matthew
--
"At least you know where you are with Microsoft."
"True. I just wish I'd
Wichert Akkerman writes:
> In woody dpkg will use a different method to determine on which
> libraries a package should depend. Until now dpkg-shlibdeps has
> used the output of ldd to determine which libraries are needed.
> This will be changed to using objdump. This however changes
> will n
Wichert Akkerman writes:
> Previously Matthew Vernon wrote:
> > I think also the principle of only rejecting uploads with RC bugs in
> > is important (ignoring the flamefests elsewhere about whether or not
> > you think maintainers should spend their lives dotting all t
Hi,
I support this proposal in principle; the (relatively)
undocumented feature in lintian means some of the details need
changing a little, so I shall modify it a little.
> However, clearly we can't expect the FTP archive maintainers to
> personally decide whether each error or bug is
Brian May writes:
> > "Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
>
> Ian> However, with the current arrangement I can't do that.
> Ian> Whenever I want to upgrade a binary package I have to update
> Ian> the libraries that it depends on to at least as recent a
> Ia
Richard Braakman writes:
> On Fri, Jan 14, 2000 at 12:05:22PM +0000, Matthew Vernon wrote:
>
> > FWIW, a package that I uploaded was rejected, with a comment "using
> > lintian would have pointed this out"; when I replied that in fact the
> > "error&quo
Richard Braakman writes:
> Indeed. Consider, though, that writing a small manpage that points
> at existing documentation is not onerous. It is about as hard as
> figuring out how to create a menu entry. I think it's part of the
> packaging process.
It's tricky to write a decent manpage if
Joey Hess writes:
> > > b) Lintian already has a local exception mechanism, which was announced
> > > to
> > >debian-devel-announce recently.
> > I've not seen that announcement, and I've been looking for such
> > announcements.
> >
> > What was the
Joey Hess writes:
> Raul Miller wrote:
> > On Thu, Jan 13, 2000 at 08:42:53PM -0800, Joey Hess wrote:
> > > Raul, I hope you're aware that
> > >
> > > a) Ian's assumption that dinstall rejects packages with lintian errors is
> > >false.
> >
> > I was not aware of that.
>
> Beleive
Roman Hodek writes:
>
> > debhelper only affects the .deb file, and it should produce correct
> > .debs regardless of version. "mybe some compilers etc." seems like
> > FUD to me.
>
> Wrong. Take as example that the potato debhelper installs docs into
> /usr/share/doc, and the stable one t
Roland Rosenfeld writes:
> On Thu, 13 Jan 2000, Matthew Vernon wrote:
>
> > Summary: -dev packages should actually provide a real libfoo.so,
> > rather than a symlink to the shared object provided by the runtime
> > package.
>
> Which means, that everybod
Package: debian-policy
Version: 3.1.1.1
Severity: normal
Hi all,
Summary: -dev packages should actually provide a real libfoo.so,
rather than a symlink to the shared object provided by the runtime
package.
The object of this proposal is to divorce the version of the -dev
package from the version
Greg Stark writes:
>
> Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:
>
> > You have a cost in being non-standard, and I don't think it is worth it
> > this time. What benefits would give us what you propose?
>
> The cost is greater than /etc/mailname or /etc/papersize ?
>
> Debian lo
[EMAIL PROTECTED] writes:
> What we could do (and I'll be happy to assist) is write some skeleton
> manpages pointing to /usr/share/info/,
> /usr/share/doc//html, etc.
This seems an excellent idea to me.
Matthew
--
"At least you know where you are with Microsoft."
"True. I just wish I'd bro
Chris Waters writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
>
> > I think the problem is really that lintian is too picky about lack
> > of man pages. At least, it's impossible to get a package by lintian
> > without setting undocumented links for every binary without a man
> > page, which
Nicolás Lichtmaier writes:
> > I think your ideas may be suitable for wishlist bugs against packages
> > that don't do what you want, but it shouldn't go into policy.
>
> No. The maintainers could close the wishlist without doing anything.
I think that they would only do so if they have a
Chris Waters writes:
> We have a *serious* problem here, IMO, and, while this proposal may
> not be the best solution, we *need* a solution. I'd like to hear some
> alternative proposals if this one is to be discarded.
> (cc'd to the most recent objectors in the probably vain hope that
> th
> This is already standard, but I think it should be into policy because I
> already saw some programs deviating from this expected behaviour.
I'm not aware of netscrape doing this, for example. And it's better to
use /etc/lynx.conf to make lynx do it too, as it prevents lusers
forgetting to co
Ben Collins writes:
> With the current implementation I have, it is a simple matter of adding a
> line for each (de)compressor wanted. I think we should choose carefully
> what compressions we allow, as it could lead to problems if we don't. For
> this reason, we should not allow arbitrary com
25 matches
Mail list logo
