to that
> effect.
If you wanna take the time to write the necessary changes to the policy
language, you can count me as a second. It's imporant that the emerging
standards be emphasised. They are being created for a reason, after all.
--
Joseph Carter <[EMAIL PROTECTED]> My
d, and
> runs easily.
I should point out that your example is bad.. dhcpcd is not well
supported and is in fact broken in the Debian package in ways that I
haven't had time and patience to track down yet - relating to its init
file mostly - but it's the only client that works wit
hat does (from non-US/*) would
> go in the following, probably.
[..]
Seconded.
--
Joseph Carter <[EMAIL PROTECTED]> GnuPG key 1024D/DCF9DAB3
Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC
The QuakeForge Project (http://quakeforge.net/) 44F
On Wed, May 17, 2000 at 09:29:39PM -0400, Ben Collins wrote:
> It's so sad to see something so simple turning into a policy debate.
At least the argument is over what to do and not who should be allowed to
do it like most Debian arguments are these days.
--
Joseph Carter <[EMAI
or not the way Linux does
things and has done them since long before anybody cared should be changed
now. Some say yes, some say no. All agree that compatibility with the
old location is important.
Hope that answers your questions.
--
Joseph Carter <[EMAIL PROTECTED]> GnuPG
ackages kernel
modules. If you want to bug people about it being broken, talk to the
device3dfx-source maintainer or to -policy. It ain't my bug and I don't
have the right to step on the toes of another maintainer to fix it just
because everyone else in the world thinks it i
On Tue, Mar 21, 2000 at 10:36:36PM +0100, Christian Surchi wrote:
[.. great volume snipped ..]
> Manoj, is this a signature? :o
Manoj's signatures seem to be directly proportional to the length of the
message they are attached to. His sig generator is an AI. Fear it.
--
Joseph Carter
ndocumented(7) is more trouble than it's worth are right
and the use of that page should be deprecated. Some of my own packages
rely on it to silence lintian errors--and this is something I think I will
change in potato. While there not being a manpage IS a problem in most of
these cases, I can
I don't
> > think logrotate would quite work.
>
> OK, so moving logrotate into important isn't necessary for cron. Which
> is good IMHO, the less packages to be moved up like that the better...
Logrotate is already in important and cron already does suggest logrotate.
--
support or not" policy (#53759)
> Change package relations policy to remove references to non-free from
> main (#51473)
> Package may be maintained by a group (#51879)
Seconded (all of them)
--
Joseph Carter <[EMAIL PROTECTED]> Debian Linux deve
Seconded.
--
Joseph Carter <[EMAIL PROTECTED]> Debian Linux developer
http://tank.debian.net GnuPG key pub 1024D/DCF9DAB3 sub 2048g/3F9C2A43
http://www.debian.org20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
it's weird, when you go on a safari to Africa
hink that's worth its own
proposal, this one is still good as it stands.
--
- Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43
- [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
---
t', and many of them will be tagged `essential' (see
> below).
>
> You must not place any packages into the `base' section before this has
> been discussed on the `debian-devel' mailing list and a consensus about
> doing that has been reached.
I do
On Fri, Dec 03, 1999 at 06:54:27PM -0800, Joey Hess wrote:
> Sure, I amend my proposal to use Antti-Juhani's wording.
And I my second for the same.
--
- Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43
- [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D
anies (an impossibility supposedly..)
--
- Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43
- [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
--
rit/ara: There's something r
just plain main.
The keyring doesn't serve much purpose without gnupg in non-US/main.
Since this creates a dependency of sorts (or at least a Recommends) for
gnupg, non-US/main is the best place for it.
--
- Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43
- [EMAIL P
therein is completely DFSG compatible.
--
- Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43
- [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
--
shaleh - unclean is just WEIRD.
heh,
On Fri, Dec 03, 1999 at 07:29:20PM -0800, Joey Hess wrote:
> Amend non-free definition (#46522)
> * Stalled.
> * Proposed by Raul Miller; seconded by Marco d'Itri, Joseph Carter
> and Joel Klecker.
> * Change definition of non-free to "contains packages which are
asily, just remove it from sources.list.
It's an interesting idea, but it's come up before and it just would not be
good for us to implement for a lot of reasons.
--
- Joseph Carter GnuPG public key: 102
On Wed, Dec 01, 1999 at 07:07:59AM -0500, Raul Miller wrote:
> Perhaps the keyring (entire keyring) should be in non-us rather than
> contrib?
Now how many months have I been saying that? =p =>
--
- Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43
- [EMAIL
main
archive (because of patents or whatever) would need a new home, such as
non-US.
This wouldn't make things like mp3 encoders instantly packagable. It
would however mean that "gimp-nonfree" would be technically in main
(though it be non-US/main, which is perfect for something that&
ugh to use apt's
binary index when using the apt method? Or perhaps use the binary index
with or without apt, just use apt's copy of it when using the apt method?
How about having dpkg use it too while you're at it? (Okay I'll shut up
now...)
--
- Joseph Carter Gn
er, that setting should
default to on. Developers should probably turn it off for the sake of
spotting packages which need to have their suggests lines fixed.
As I said above, this has little to do with Enhances' usefulness.
--
- Joseph Carter GnuPG public key: 1024D/D
we decided to have a data dist which would be part of Debian but
main would not be allowed to depend on things in it. But I haven't seen
anything indicating if or when this will be implemented. All this leads
me to believe we really need to know what we're going to do before we do
a
r issues (or I could be mistaken..) It's a shame too,
but other than someone with a LOT of patience who happens to be good at
font editing (I only know of ONE free font editor and it does bdf fonts
only...) I don't see much that we can do about it now. =<
I'm convinced, we can
his concern applies to most policy updates, not just the two
> you mentioned. More generally, we need some kind of release management
> for debian-policy and that should somehow interelate to general debian
> release management.
>
> This a rather larger topic, in general, but hopefull
eople trying to do all of those things cooperate and things happen
smoothly.
--
- Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43
- [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
policy proposal to include
> Apps/Browser, I'll second.
I'd support either Apps/Disk or Apps/Browser, I can see uses for both.
--
- Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43
- [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
-
7;s easy to use the LESSOPEN feature to make such
> decompression automatic.
This causes a strange and untracked so far bug across a ssh connection if
.bash_profile actually puts anything on the screen. It's WEIRD.
--
- Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C
package in a debian system to be
> able to read the docs and zless is already installed in every base system.
I think Copyrights should NEVER be compressed for the sole reason that we
need to make them as visible as possible without shoving them down
people's throats. I realize the triviality in
eriously from being compressed.
I understand the theoretical 4095 byte file, but if you changed it to 2k
there would be the theoretical 2047 byte file and the 1023 byte file ...
IMO it ain't broke, soo...
--
- Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43
- [EMAIL
X11R6/include/X11/{bit,pix}maps -> /usr/share/icons
> as another possibility.
You mean to tell me that I have a 1024x768 icon? =p
I can see /usr/share/{pix,bit}maps though---I'm kinda bugged about lumping
every graphic on the system into one directory.
--
- Joseph Carter GnuPG
oposal, could I get you to email
> it to [EMAIL PROTECTED]
Consider this it. =>
--
- Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43
- [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
---
that doesn't require all packages use bz2. If a
package can be gotten bz2 upstream that's fine. If not, I think pristine
source is more important.
Reasonable transition and encouragement to use bz2 is fine. Require it
and I'll get annoyed.
--
- Joseph Carter GnuPG
n the presence or absence of files of
> > ^
> > > + directories in '/usr/local' for normal operation.
> >
> > Do you mean 'or' there?
>
> Yes, thanks!
Okie, my second goes double for me now, much cleaner wording. =
I'd say it's got a nice consensus. Anyone
who cares has weighed in and their objection (which was mine too) that we
had yet to see such an example was resolved. I'm satisfied, and I'm
guessing so is everyone else who was concerned.
--
- Joseph Carter GnuPG public key
ded into
> daemons. The proposal is to change that so only dynamic uid's may
> be used.
Did I forget to second this? I do so now---LSB is going to have to
mandate this anyway I suspect.
--
- Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43
- [EMAIL PRO
nk having both locations included in system.yawmrc is reasonable.
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77 8E
just deprecated (see rc.boot(5)).
>
> The question of local rc.? directories is still an active topic of
> discussion.
rc.boot makes perfect sense as a simple way for local sysadmins to add
things to be run when the machine boots. I think no package has any
business touching it (and no
onded.
I really think the "require" and "mandatory" parts are a Bad Plan. If bz2
support is ACTUALLY WRITTEN I would support policy that recommends using
bz2 if upstream does. I think people with huge packages will do the right
thing because it's the right thing in almost
> * Modifies policy to explicitly state that programs must not rely on
> anything in /usr/local
THis is existing practice. If it's not policy, it should be. Seconded.
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
Gnu
ting packages in main. Is that what we want?
non-US/main actually, given the scope of the LZW patent. I have no
problems with this at all and if I didn't second the proposal yet (I'm
pretty sure I did but it's been a long week and it's only Monday) I'm
doing so now. =&
buy
little plastic clips that are of course patented. Whatevver you do, don't
start selling bent paper clips or they'll sue you for patent infringement!
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2
meant above was to provide the same shell code as a reference
implementation. That's what debhelper uses and it doesn't require any
helper packages.
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g
both
/opt/bin and /usr/local/bin? Compatibility provided to prevent breaking
things unexpectedly ? Why not just suggest one should be linked to the
other? (Most people do that already I think--I used to but I've since
given /opt its own partition)
--
Joseph Carter <[EMAIL PROTECTED]>
of promoting the bug on this to Priority: important,
> but which bug?]
>
> --
> Raul
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>
--
Joseph Carter <[EMAIL PROTECT
On Sun, Sep 19, 1999 at 10:32:59AM +0200, Marco d'Itri wrote:
> On Sep 19, Joseph Carter <[EMAIL PROTECTED]> wrote:
> >I think the practice of using static IDs should be deprecated (and
> >packages doing it should get lintian warnings..) I disagree with banning
&g
here are some such config files. I believe tetex has one, for
> > example.
>
> Which is...?
I have no idea offhand. I just know it's created by inittex and it
doesn't matter if I tell dpkg to replace mine or not, it will always be
regenerated by initex.
--
Joseph Carter
to get fixed
> > before they have bugs filed against them.
>
> Is a problem if bugs get filed?
It's a problem if there's no transition to speak of. We apparently have
decided not to make policy that makes a bunch of packages instantly non-
compliant without a reasonable tra
as one, for
example.
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77
fixed
before they have bugs filed against them.
If Andreas is agreeable, I'm willing to second the proposal.
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D
On Fri, Sep 17, 1999 at 12:17:59PM -0700, Joey Hess wrote:
> /var/mail and /var/spool/mail (#42052)
> * Old.
> * Proposed by Joseph Carter; seconded by Gordon Matzigkeit, Joey
> Hess and Santiago Vila.
> * This outlines a migration path from /var/spool/mail to /var/
nts in a serious way' should either be fixed (ideally), or not
> included in Debian at all.
Or moved to project/experimental.
This is a second =>
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44
depending on whether they've exhausted their
stock of the old version...
This is precisely why I believe the update joeyh wants to make to slink
should NOT be a point release of slink but rather a new version. I'd
rather not have only some versions of slink which you get on the luck of
ases are stable, but there is nothing
that says we have to mimic the kernel version system. =p
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2
resolved?
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77 8E E2 29 96 C9 44 5F BE
-
On Sat, Sep 04, 1999 at 12:25:09PM -0700, Joseph Carter wrote:
> And I have yet to hear a better idea to solve the problem. I have said I
> would withdraw my proposal if I heard another reasonable idea. Simply not
> using dpkg-shlibdeps isn't IMO reasonable, neither is hacking
her is hacking a binary.
>
> Agreed, can we please just push this through?
Is that a second? =>
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 8
On Fri, Sep 03, 1999 at 11:04:29AM -0700, Joey Hess wrote:
> Method for shlibs to work with libfoo.so (#42236)
> * Stalled for 2 weeks.
> * Proposed by Joseph Carter; seconded by Anthony Towns and Aaron Van
> Couwenberg.
> * This is a proposal to make binary-only shared li
only localhost, but in reality
if you want to read docs by web browser you should probably be using dwww
anyway which CAN deal with both since it's a perl CGI and could easily
build a composite listing of both /usr/doc and /usr/share/doc.
JMO,FWIW...
--
Joseph Carter <[EMAIL PROTECTED]>
f how Maildir format would work.. :)
The only console MUA I know of which may not support maildir is elm-me+
and even it might. Still, I believe it should be done by the individual
sysadmin---even though I have done it myself. The admin is the best
person to decide if the changes made by switch
On Fri, Aug 06, 1999 at 03:46:34PM -0700, Joey Hess wrote:
> Method for shlibs to work with libfoo.so (#42236)
> * Under discussion.
> * Proposed by Joseph Carter.
> * This is a proposal to make binary-only shared libs that have no
> soname work with dpkh-shlibdeps. The id
have to consider people with a mail partition.
I would support the ability to make this the default for a system, but I
can't say that it should be done globally and universally. We're all
aware of the dangers of NFS. If there was a good way to fix the problem
we'd have fixed it ten
a bugfix because its primary
beneficiary is non-free software.
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED -
FHS 2.1 includes /var/mail, but says it may be a symlink if need be.
So essentially Ian is trying to kill the proposal before FHS 2.1 has a
chance to be published and recommend this sort of approach. Wonderful.
Ahh, how appropriate can a sig get?
--
Joseph Carter <[EMAIL PROTECTED]>
e reasons for us not to change: it is hard to do right, as the
> discussion has shown, and if we get it wrong we risk making people's
> mail systems fall over or even losing mail.
Creating a symlink is not hard. It does not lose mail. It does not harm
the system.
--
Joseph Ca
binary or
library which does something you didn't anticipate when writing that
script?
Because it makes dpkg-shlibdeps act more intelligently in such cases?
Because the current way dpkg-shlibdeps mis-mangles ldd output and panics
in the case of a library without a soname should be conside
he middle of the night
while I am trying to sleep.
That said, I think policy should mention this sort of thing for the sound
devices. Perhaps you might provide a proposal indicating the exact
changes to policy you're looking for? I'd be interested in reading it.
--
Joseph Carter <[EMAIL
On Sun, Aug 08, 1999 at 10:11:56AM -0700, Joey Hess wrote:
> I just realized something. With all this furur over /usr/share/doc,
> we seem to have skipped right over the question of where do arch-dependant
> example files go. Where?
/usr/bin. =p
--
Joseph Carter <[EMA
On Sat, Aug 07, 1999 at 10:39:13AM +1000, Anthony Towns wrote:
> > Method for shlibs to work with libfoo.so (#42236)
> > * Under discussion.
> > * Proposed by Joseph Carter.
> > * This is a proposal to make binary-only shared libs that have no
> > soname
up for LD_PRELOAD, but still I need dpkg-shlibdeps not to
die and abort building of the package just because it doesn't know how to
handle an unversioned shlib.
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC
On Fri, Aug 06, 1999 at 03:46:34PM -0700, Joey Hess wrote:
> Method for shlibs to work with libfoo.so (#42236)
> * Under discussion.
> * Proposed by Joseph Carter.
> * This is a proposal to make binary-only shared libs that have no
> soname work with dpkh-shlibdeps. The id
On Fri, Aug 06, 1999 at 04:21:40PM +0300, Antti-Juhani Kaijanaho wrote:
> > Why do you think that we couldn't make a decision now?
>
> Because we haven't been able to do so in the last few weeks.
What is now done is AFAIK in the hands of the technical committee.
--
a metric of technical
> correctness, or even merit.
We apparently need to find some way to deal with controversial technical
issues. A month's senseless flaming and then appealing to the technical
committee is going to get slightly annoying.
--
Joseph Carter <[EMAIL PROTECTED]&g
s basically a cop-out, postponing the work
> until after potato's release. I agree with that, but the powers that be
> regrettably do not seem to be on my side.
I agree with it. => Not that I'm a power or anything, but I agree all
the same.
--
Joseph Carter <[EMAIL PROTECT
re. For the effort
required to undo this change, we might as well just come up with a symlink
solution or something and move forward.
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
PGP 2
igured.
>
> `dpkg' will not configure packages whose dependencies aren't
> satisfied.
>
> If dpkg does run postinsts in the wrong order, then we might just as well
> turn all depends fields into pre-depends.
Okay, you're right. See what all this argui
m able to think
coherently or in response to other comments made or something. Oh, and
thanks for the nifty new sig! =D
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50B
.
I think this is almost too much to make a transition even now. And I
believe that if we don't come up with a better solution in a week or so,
we'd be best to simply drop the issue---it won't matter anymore.
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/L
MTA
depending on it, then a pre-dep is not needed. It was my understanding
that dpkg could get confused this way and run things in the wrong order.
If we can be sure of this and it is guaranteed to be so, a pre-dep is not
needed.
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux d
object to
a proposal. But then as I said it's almost too late to implment this now.
While we've been fighting about it on -policy, many others were simply
uploading packages with /usr/share/doc. If this pattern continues as I am
certain it will, it'll be too late to have a transition
kages to not happen until you got a fixed
version?) If you start it in postinst, pre-dep base-files. I probably
should add post an ammended proposal addressing all this shouldn't I?
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG:
27;m saying our effort should be spent making /usr/share/doc work, not
debating whether or not we should be making it work or just going back go
/usr/doc... We're past that point already.
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A
gs if symlinks are
used.
The thought of moving /usr/doc is one I have supported, however in every
message I've written supporting it I've said up front that dpkg ABSOLUTELY
MUST BE FIXED prior to this happening.
--
Joseph Carter <[EMAIL PROTEC
ity to just symlink /usr/doc to /usr/share/doc after a move. It's
been noted that this move would not be atomic, but it could be done
safely.
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9
--not a small group deciding that they want to second guess
everyone else.
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6:
state of the distibution is a Good Thing?
>
> Well, I don't see any grave problems in having docs in two different
> places. No essential part of the system breaks by that, it just causes
> some minor inconvenience.
inconvenience yes, minor no. It's damned annoying. But I&
ake that long for the decision to decide whether or not we should decide
to do these things or not will be made.
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7
dpkg and symlinks.
In any event unlike the symlinks issue, there is no harm that is not
already clearly documented in using /var/mail. You might have to run a
few extra installs or configures but if your dselect method is that broken
you're going to have to do that anyway---and alread
On Tue, Aug 03, 1999 at 12:05:39PM +0200, [EMAIL PROTECTED] wrote:
> Dear Joseph Carter,
>
> I'm sorry to shout but please read what I write.
>
> > All right dammit, here we go... built a package crap 1.0-1, here is the
> > listing:
> >...
> > /usr/lib
On Tue, Aug 03, 1999 at 10:56:22AM +0200, [EMAIL PROTECTED] wrote:
> I proposed:
>
> >> 1. REQUIRE that /usr/doc is a symlink to the FHS directory /usr/share/doc.
>
> Joseph Carter replied:
>
> > Breaks dpkg. Propose it all you want, but it's not going to
will happen if lots of essential packages in potato
> depend on libc 2.1. Do we plan to avoid it this time?
No way to avoide it. The essential packages were the ones that broke when
we upgraded. It may be easier to fix the dselect methods that don't order
packages to be quite honest. Th
link magic at some point. Not
that it isn't a moot point unless you fix dpkg first.
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 D
every user will
> hate the transition as it's being carried out now.
Then someone needs to come up with a solution, NOW. Not in a month, not
in three months, not after we release potato. I don't like having two doc
directories to look in either, but we seem to be ru
m ready to agree with the small and growing
group of people who are saying screw the transition---the only thing it
really hurts is /usr/doc/pac and being a creature of habit that
annoys me. But I'd deal with it.
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux develo
e
> > action, but they also choose to refute the objection, and return the
> > matter to supermajority vote.
>
> How about only allowing formal objections to amendments? And yes, I think
> several should be needed to kill it.
Four more than the number of seconds might be
a dozen proposals and everyone seems to be formally objecting to every
proposal that isn't theirs ...)
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC
On Sat, Jul 31, 1999 at 09:55:31PM -0700, Joey Hess wrote:
> Joseph Carter wrote:
> > I think the html changelog SHOULD be there since that is its native form.
> > lynx can be guaranteed to make a mess of anything more complex than a
> > simple HTML file and as a result the or
y to suggest exact wording changes to the policy, be
my guest please! Otherwise I am just hoping to start the discussion and
get minds rolling in the right direction. So consider this a
meta-proposal for the moment.. =p
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux develop
On Sat, Jul 31, 1999 at 01:07:40PM +1000, Anthony Towns wrote:
> On Fri, Jul 30, 1999 at 07:55:13PM -0700, Joseph Carter wrote:
> > read "mv" as "cp, verify success, rm old, create symlink, and the whole
> > time deal with things like dropped .dhelp files in /usr
1 - 100 of 302 matches
Mail list logo
