Re: Bug#51842: [PROPOSED] closing hole in DFSG that can force you to include some text in advertisement

[Manoj Srivastava]

>>"Joey" == Joey Hess <[EMAIL PROTECTED]> writes:

 Joey> Ok, perhaps it wasn't clear. My meaning was that I think we
 Joey> should solicit Bruce's opinion on any changes to the DFSG. It

I fail to see why one would do that any more than, say, RMS or
 ESR, or Alan Cox or Linus. 

 Joey> would just be one opinion amoung many, I'm sure.

 Joey> I think it's useful to look at Bruce as the upstream author of
 Joey> the DFSG.  After all, he is the primary author. My

No way in hell. The DFSG was written during a prolonged
 discussion, and the mailing list contributed to the final form. Buce
 is not more the upstream author of the DFSG than CHristian Schartz is
 the upstream author of Debian policy.

Secondly, Debian should be in total charge of the criteria
 that the project uses to define what is free and what is not.  This
 is a core, critical, aspect of the Pr5oject, and in no way, shape, or
 form should it be under external decisi0on or influence.

If we can't even claim ownership of the DFSG, I shall
 seriously launchan effort to disown it, and start over with a
 document we can control.

This is a major deal to me.

 Joey> conversations with him have revealed that he has a deeper
 Joey> understanding of the tradeoffs involved in it and the
 Joey> underlying reasons for what is currently in it than most other
 Joey> people do, and thus I value his advise on the DFSG.

I value lots of peoples advice. ESR. Linus. Alan Cox. The
 Pope. My wife.  Does that mean they control what Debian decides is
 free? Heck, no. 

 Joey> Just like with a normal upstream author, we should try to avoid
 Joey> a fork.

I totally reject the notion that there is an upstrewam author
 involved. But, if there is, we should rescind the document and create
 a new one, whenever we so desire.

 Joey>   However, just as with a normal upstream author, we
 Joey> reserve the right to override their decisions if that is
 Joey> necessary for Debian.

I would not like to be beholden to an outsider for something
 that is at the core of the project. 

manoj
-- 
 "No, no, I don't mind being called the smartest man in the world.  I
 just wish it wasn't this one." Adrian Veidt/Ozymandias, WATCHMEN
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Bug#50832: AMENDMENT] Clarify meaning of Essential: yes

[Chris Waters]

Anthony Towns  writes:

> [1  ]
> On Fri, Dec 10, 1999 at 02:06:47AM -0800, Chris Waters wrote:
> > Furthermore, it occurs to me that the problem isn't just essential
> > packages.  If libc6 fails to work during an upgrade, we're equally bad
> > off, but libc6 isn't essential.  So, the proposal is not only
> > ambiguous and redundant, but misdirected as well.  Only the fact that
> > it's harmless (because it's redundant) keeps me from formally
> > objecting.  :-)

> *sigh*

> How about coming up with something better then?

Better how?  The situation with bash is already a bug, so we don't
need to change policy to deal with that.  So what is it you're trying
to accomplish?  What is it you really want?

Here's a thought: the system should actually *pre*-depend on packages
that are required by the packaging system itself.  But essential
packages are treated (at least by dpkg) as universal dependencies, not
universal pre-dependencies.

If we fix *that* one, then the bug in bash magically becomes
not-a-bug, and the whole need for this proposal disappears, just like
that.  (AFAICT.)

Better to fix our internal bugs than to enshrine them forever in
policy.  Essential packages *should* be able to use the alternatives
system without exploding.

So, maybe better would be to file a bug against dpkg, not policy.
-- 
Chris Waters   [EMAIL PROTECTED] | I have a truly elegant proof of the
  or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.

Re: Bug#50832: AMENDMENT] Clarify meaning of Essential: yes

[Seth R Arnold]

On Sat, Dec 11, 1999 at 01:09:29AM -0800, Chris Waters wrote:
> Here's a thought: the system should actually *pre*-depend on packages
> that are required by the packaging system itself.  But essential
> packages are treated (at least by dpkg) as universal dependencies, not
> universal pre-dependencies.

What happens if a new version of dpkg has two versioned predeps that declare
each other as predeps? (Yes, this does seem rather a contrived situation,
but it is an extreme -- are there less extreme situations that are more
plausible? How does dpkg handle such things now? :)

Just curious more than anything else...


-- 
Seth Arnold | http://www.willamette.edu/~sarnold/
Hate spam? See http://maps.vix.com/rbl/ for help
Hi! I'm a .signature virus! Copy me into
your ~/.signature to help me spread!

Re: Bug#50832: AMENDMENT] Clarify meaning of Essential: yes

[Anthony Towns]

On Sat, Dec 11, 1999 at 01:09:29AM -0800, Chris Waters wrote:
> > On Fri, Dec 10, 1999 at 02:06:47AM -0800, Chris Waters wrote:
> > > Furthermore, it occurs to me that the problem isn't just essential
> > > packages.  If libc6 fails to work during an upgrade, we're equally bad
> > > off, but libc6 isn't essential.  So, the proposal is not only
> > > ambiguous and redundant, but misdirected as well.  Only the fact that
> > > it's harmless (because it's redundant) keeps me from formally
> > > objecting.  :-)
> > *sigh*
> > How about coming up with something better then?
> Better how?  The situation with bash is already a bug, so we don't
> need to change policy to deal with that.  So what is it you're trying
> to accomplish?  What is it you really want?

What I want is for this bash bug never to occur again. Nor anything like it.

The reason the bash bug occured is becuase neither Torsten nor I realised
that having essential packages work even unconfigured or after errors was
necessary. We didn't realise this because it's not documented anywhere, and
it's not a particularly obvious thing to have happen.

I've already gone over this. It's all in the bug logs.

> Here's a thought: the system should actually *pre*-depend on packages
> that are required by the packaging system itself.  But essential
> packages are treated (at least by dpkg) as universal dependencies, not
> universal pre-dependencies.

No, they're treated much more like pre-dependencies, actually: like
pre-dependencies there's no particular guarantee that they'll be
configured when you need them. Like pre-dependencies they're already
there when you start unpacking them.
 
> If we fix *that* one, then the bug in bash magically becomes
> not-a-bug, and the whole need for this proposal disappears, just like
> that.  (AFAICT.)

And make dpkg's ordering rules more strict, for no good reason.

I've gone over this, too.

Sheesh.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgpdQtQnZCuGI.pgp
Description: PGP signature

Bug#42554: weekly policy summary

[Joey Hess]

Anthony Towns wrote:
> What do people think of:

Well, it's significantly different from the original proposal, which I
disliked. i like your version much better, and would second it if it were
formally proposed.

> --- -   Wed Dec  8 22:11:23 1999
> +++ policy.text Wed Dec  8 22:11:11 1999
> @@ -2518,10 +2518,9 @@
>   compressed nor be a symbolic link.
>  
>   In addition, the copyright file must say where the upstream sources
> - (if any) were obtained, and explain briefly what modifications were
> - made in the Debian version of the package compared to the upstream
> - one.  It must name the original authors of the package and the Debian
> - maintainer(s) who were involved with its creation.
> + (if any) were obtained, and it must name the original authors of
> + the package and the Debian maintainer(s) who were involved with
> + its creation.
>  
>   /usr/share/doc/ may be a symbolic link to a directory in
>   /usr/share/doc only if two packages both come from the same source and
> @@ -2550,11 +2549,13 @@
>after all, the GPL does not "document" anything, it is merely a
>license.
>  
> - Do not use the copyright file as a general `README' file.  If your
> - package has such a file it should be installed in
> - `/usr/share/doc//README' or `README.Debian' or some other
> - appropriate place.
> +6.6. Debian-specific Documentation
> +--
>  
> + A package may contain a file /usr/share/doc//README.Debian
> + (or README.Debian.gz). This should be used to document any
> + Debian-specific modifications made to the package, any compilation
> + options that have been set, and any other user-visible changes.

-- 
see shy jo