Re: [PROPOSED] Change package relations policy to remove references to non-free from main

[Raul Miller]

> > > If the references are never displayed *to people who dio not
> > >  want* tham, why is that so bad? And why are we going through hoops to
> > >  impose the religion on everyone else as well?

Raul Miller wrote:
> > What do you mean by "display"?  You want to chain people to dselect?

On Wed, Dec 01, 1999 at 02:35:29PM -0800, Joey Hess wrote:
> Dselect is the *only* program that ever does anything with suggests.

What about that perl one liner?  Or just plain old dpkg -s?  Or vi
/var/lib/dpkg/status?  Or, apt-cache dumpavail?  Or future simple programs
of various sorts?

Perhaps the suggestion is that we put something into policy to restrict
the handling of these cases?

-- 
Raul

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

[Julian Gilbey]

> So let us just pretend that we just implement one of
>  weak-suggests and reverse-suggests and call it Enhances, shall we? ;-)

I think there appears to be enough of a reason to allow both of these:
they both have their strengths and weaknesses, but both are useful in
some contexts:

weak-suggests is to be used where:
  a package in main/contrib/non-free suggests one in non-US/anything
  a package in (non-US/)main suggests one in (non-US/)contrib or
(non-US/)non-free
  a package in (non-US/)contrib suggests one in (non-US/)non-free

Then if the hierarchy is unavailable (how do we know that?), dselect
should ignore the suggestion, otherwise, it should display it.

reverse-suggests (enhances), on the other hand, should only be allowed
to reverse-suggest a package which is at least as free as the
suggesting package, so that we don't have to worry about the hierarchy
not being present.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

[Julian Gilbey]

> People declare inappropriate Suggests all the time; anything we can do
> to reduce that would be a help.  Suggests should have documentation
> attached explaining *why* the suggestion is made.  Someone suggests
> "netscape", and that really loses when they should suggest
> "www-browser"; but then lots of things that Provide www-browser are
> not really browsers at all but (say) http proxies.

That is why we have a Bug Tracking System: these are bugs and should
be dealt with through the BTS.  Making policy changes to solve these
problems is pointless: they will still need to be reported as bugs.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

[Thomas Bushnell, BSG]

Julian Gilbey <[EMAIL PROTECTED]> writes:

> That is why we have a Bug Tracking System: these are bugs and should
> be dealt with through the BTS.  Making policy changes to solve these
> problems is pointless: they will still need to be reported as bugs.

Quite right, perhaps I shouldn't have interjected that part into the
discussion.

Re: Submitting bugs ? (Was: Getting rid of section "base" ?)

[Joey Hess]

Darren O. Benham wrote, about the removal of the base section:
> Is this, basicly, a part of policy now?

Actually, policy is quite out of date on the issue:

2.3.6. Base packages


 The packages included in the `base' section have a special function.
 They form a minimum subset of the Debian GNU/Linux system that is
 installed before everything else on a new system.  Thus, only very few
 packages are allowed to go into the `base' section to keep the required
 disk usage very small.

 Most of these packages should have the priority value `required' or at
 least `important', 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.

Since Adam tells us this is no longer true and the boot-floppies team
decides what goes in the base system, and since we seem to have a consensus
that the base section is then unnecessary, policy needs to be updated. 

Since other parts of policy refer to "the base system", we still need some
definition of what that system is, or quite a few paragraphs (see end of
this email) would need to be changed. Here is one way we could reword policy:

| 2.3.6. The base system 
  --

|
|   The base system is a minimum subset of the Debian GNU/Linux system that is
installed before everything else on a new system.  Thus, only very few 
|   packages are allowed to go into the base system to keep the
|   required disk usage very small.

Most of these packages should have the priority value `required' or at
least `important', 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 considered making some change to say that debian-boot has control of what
goes in there, but I don't think that's really necessary. 

-- 
see shy jo


Appendix: references to "base" in policy:

 The Debian base distribution provides the `tempfile' and `mktemp'
 utilities for use by scripts for this purpose.
...
 If a package needs any special device files that are not included in
 the base system, it has to call `makedev' in the `postinst' script,
 after asking the user for permission to do so.
...
 You must ask for a user or group id from the base system maintainer,
 and must not release the package until you have been allocated one.
 Once you have been allocated one you must make the package depend on a
 version of the base system with the id present in /etc/passwd' or
 `/etc/group', or alternatively arrange for your package to
 create the user or group itself with the correct id (using `adduser')
 in its pre-or post-installation script (the latter is to be preferred
 if it is possible).

 On the other hand, the program may able to determine the uid or gid
 from the group name at runtime, so that a dynamic id can be used. In
 this case you must choose an appropriate user or group name, discussing
 this on `debian-devel' and checking with the base system maintainer that
 it is unique and that they do not wish you to use a statically
 allocated id instead.  When this has been checked you must arrange for
 your package to create the user or group if necessary using adduser' in
 the pre- or post-installation script (again, the latter is to be
 preferred if it is possible).

(I think these two paragraphs are just out of date, they should be talking
about base-passwd.)

 These are two scripts provided in the Debian base system that check the
 EDITOR and PAGER variables and launches the appropriate program or
 falls back to `/usr/bin/editor' and `/usr/bin/pager', automatically.
...
 Since the Debian base system already provides an editor and a pager
 program, there is no need for a package to depend on `editor' and
 `pager', nor is it necessary for a package to provide such virtual
 packages.
...
 The mail spool is /var/spool/mail' and the interface to send a mail
 message is `/usr/sbin/sendmail' (as per the FHS).  The mail spool is
 part of the base system and not part of the MTA package.

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

[Chris Waters]

[in one message]
Raul Miller <[EMAIL PROTECTED]> writes:

> Personally, I think that hard-coding into a DFSG package a reference
> to some non-DFSG package is rather grotesque.  I'm disappointed that
> we disagree on this issue.

[in another message]
Chris Waters <[EMAIL PROTECTED]> writes:

> The other objection I've seen is, basically, "the purity of the system
> is marred by the very presence of even the *names* of non-free
> packages."  My opinion of this notion is unprintable.  :-)

I can't think of anything to add to that.  Except to comment that it
might be rather difficult to document samba if you could never refer
to non-free software.  :-)

cheers
-- 
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: [PROPOSED] Change package relations policy to remove references to non-free from main

[Anthony Towns]

> Raul Miller <[EMAIL PROTECTED]> writes:
> > Personally, I think that hard-coding into a DFSG package a reference
> > to some non-DFSG package is rather grotesque.  I'm disappointed that
> > we disagree on this issue.

I don't think that's any worse than having a GPL-compatible package
reference a non-GPL-compatible package, if we were to have a gpl-only
distribution.

Personally, I think as far as words in a packages file go, or as far as
the output from dpkg -s goes, we ought to be satisfied with just ensuring
that suggests: foo is only done from a Debian package if foo is another
Debian package.

Standard user tools like dselect and gnome-apt, or whatever, are something
of a different matter though.

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


pgp3JcJpu9Eck.pgp
Description: PGP signature

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

[Raul Miller]

> [in one message]
> Raul Miller <[EMAIL PROTECTED]> writes:
> 
> > Personally, I think that hard-coding into a DFSG package a reference
> > to some non-DFSG package is rather grotesque.  I'm disappointed that
> > we disagree on this issue.
> 
> [in another message]
> Chris Waters <[EMAIL PROTECTED]> writes:

On Fri, Dec 03, 1999 at 12:19:57AM -0800, Chris Waters wrote:
> > The other objection I've seen is, basically, "the purity of the system
> > is marred by the very presence of even the *names* of non-free
> > packages."  My opinion of this notion is unprintable.  :-)
> 
> I can't think of anything to add to that.  Except to comment that it
> might be rather difficult to document samba if you could never refer
> to non-free software.  :-)

You're suggesting you don't recognize the difference between package
structure and documentation?

-- 
Raul

Re: Submitting bugs ? (Was: Getting rid of section "base" ?)

[Darren O. Benham]

And policy does or does not dictate sections?

On Thu, Dec 02, 1999 at 12:08:11AM -0800, Joey Hess wrote:
> Darren O. Benham wrote, about the removal of the base section:
> > Is this, basicly, a part of policy now?
> 
> Actually, policy is quite out of date on the issue:
> 
> 2.3.6. Base packages
> 
> 
>  The packages included in the `base' section have a special function.
>  They form a minimum subset of the Debian GNU/Linux system that is
>  installed before everything else on a new system.  Thus, only very few
>  packages are allowed to go into the `base' section to keep the required
>  disk usage very small.
> 
>  Most of these packages should have the priority value `required' or at
>  least `important', 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.
> 
> Since Adam tells us this is no longer true and the boot-floppies team
> decides what goes in the base system, and since we seem to have a consensus
> that the base section is then unnecessary, policy needs to be updated. 
> 
> Since other parts of policy refer to "the base system", we still need some
> definition of what that system is, or quite a few paragraphs (see end of
> this email) would need to be changed. Here is one way we could reword policy:
> 
> | 2.3.6. The base system 
>   --
> 
> |
> |   The base system is a minimum subset of the Debian GNU/Linux system that is
> installed before everything else on a new system.  Thus, only very few 
> |   packages are allowed to go into the base system to keep the
> |   required disk usage very small.
> 
> Most of these packages should have the priority value `required' or at
> least `important', 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 considered making some change to say that debian-boot has control of what
> goes in there, but I don't think that's really necessary. 
> 
> -- 
> see shy jo
> 
> 
> Appendix: references to "base" in policy:
> 
>  The Debian base distribution provides the `tempfile' and `mktemp'
>  utilities for use by scripts for this purpose.
> ...
>  If a package needs any special device files that are not included in
>  the base system, it has to call `makedev' in the `postinst' script,
>  after asking the user for permission to do so.
> ...
>  You must ask for a user or group id from the base system maintainer,
>  and must not release the package until you have been allocated one.
>  Once you have been allocated one you must make the package depend on a
>  version of the base system with the id present in /etc/passwd' or
>  `/etc/group', or alternatively arrange for your package to
>  create the user or group itself with the correct id (using `adduser')
>  in its pre-or post-installation script (the latter is to be preferred
>  if it is possible).
> 
>  On the other hand, the program may able to determine the uid or gid
>  from the group name at runtime, so that a dynamic id can be used. In
>  this case you must choose an appropriate user or group name, discussing
>  this on `debian-devel' and checking with the base system maintainer that
>  it is unique and that they do not wish you to use a statically
>  allocated id instead.  When this has been checked you must arrange for
>  your package to create the user or group if necessary using adduser' in
>  the pre- or post-installation script (again, the latter is to be
>  preferred if it is possible).
> 
> (I think these two paragraphs are just out of date, they should be talking
> about base-passwd.)
> 
>  These are two scripts provided in the Debian base system that check the
>  EDITOR and PAGER variables and launches the appropriate program or
>  falls back to `/usr/bin/editor' and `/usr/bin/pager', automatically.
> ...
>  Since the Debian base system already provides an editor and a pager
>  program, there is no need for a package to depend on `editor' and
>  `pager', nor is it necessary for a package to provide such virtual
>  packages.
> ...
>  The mail spool is /var/spool/mail' and the interface to send a mail
>  message is `/usr/sbin/sendmail' (as per the FHS).  The mail spool is
>  part of the base system and not part of the MTA package.
> 

-- 
Please cc all mailing list replies to me, also.
=
* http://benham.net/index.html<[EMAIL PROTECTED]>   <><  *
*  * ---

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

[Raul Miller]

> > Raul Miller <[EMAIL PROTECTED]> writes:
> > > Personally, I think that hard-coding into a DFSG package a reference
> > > to some non-DFSG package is rather grotesque.  I'm disappointed that
> > > we disagree on this issue.

On Thu, Dec 02, 1999 at 07:20:39PM +1000, Anthony Towns wrote:
> I don't think that's any worse than having a GPL-compatible package
> reference a non-GPL-compatible package, if we were to have a gpl-only
> distribution.

Huh?

If we were building an independent (not debian) distribution 
then I can see your point.

But we've already got a definition for what's debian vs. what's not.

And the point is: we are supposed to support non-free packages, we're
not supposed to make them a part of debian.

> Personally, I think as far as words in a packages file go, or as far as
> the output from dpkg -s goes, we ought to be satisfied with just ensuring
> that suggests: foo is only done from a Debian package if foo is another
> Debian package.

Exactly.

Non-free packages aren't debian packages -- even if we've graciously
decided to distribute them from our ftp sites.

I think a lot of people have lost sight of this.

-- 
Raul

Re: Submitting bugs ? (Was: Getting rid of section "base" ?)

[Joey Hess]

Darren O. Benham wrote:
> And policy does or does not dictate sections?

Policy dictates the base section, and indicates that other sections exist,
but does not describe them.

-- 
see shy jo

Re: Submitting bugs ? (Was: Getting rid of section "base" ?)

[Darren O. Benham]

So (whoever was going to do this) filing bugs against packages for being in
base section is premature until the amendment has been actually accepted
into policy...

On Thu, Dec 02, 1999 at 10:40:36AM -0800, Joey Hess wrote:
> Darren O. Benham wrote:
> > And policy does or does not dictate sections?
> 
> Policy dictates the base section, and indicates that other sections exist,
> but does not describe them.
> 
> -- 
> see shy jo
> 

-- 
Please cc all mailing list replies to me, also.
=
* http://benham.net/index.html<[EMAIL PROTECTED]>   <><  *
*  * ---*
* Debian Developer, Debian Project Secretary, Debian Webmaster  *
* <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>  *
* <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>   *
=


pgpVdyIFN6EnD.pgp
Description: PGP signature

Re: Submitting bugs ? (Was: Getting rid of section "base" ?)

[Joey Hess]

Darren O. Benham wrote:
> So (whoever was going to do this) filing bugs against packages for being in
> base section is premature until the amendment has been actually accepted
> into policy...

So if people think the way I handled it in my proposal was ok, I'll make
that a formal proposal.

-- 
see shy jo

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

[Manoj Srivastava]

>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:

 Raul> On Fri, Dec 03, 1999 at 12:19:57AM -0800, Chris Waters wrote:
 
 >> I can't think of anything to add to that.  Except to comment that it
 >> might be rather difficult to document samba if you could never refer
 >> to non-free software.  :-)

 Raul> You're suggesting you don't recognize the difference between package
 Raul> structure and documentation?

I would suggest that ethically speaking (and we do seem to be
 speaking of ethics and religion), if the package talks all about
 non-free packages in the description and all over the docs, your poor
 users are going to be made way more aware of the bad, nast6y non-free
 software that is not supposed to exist.

Jeeze.

manoj
-- 
 Nothing succeeds like success. Alexandre Dumas
Manoj Srivastava   <[EMAIL PROTECTED]>  
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

[Manoj Srivastava]

Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:

 Raul> This isn't about "talking about other packages".

Then it should be. Your raison de etre seems to be that good
 users shall find references to non-free software r5epugnant, and
 hence one must purge all references from the package structure.

It doesn't matter to you that the users shan't be offered to
 install these packages unless they explicitly ask for them.

That seems to me, logically, that these people should be
 totally put off by packages talking about non-free software in their
 face.

Hell, Suggests are only relevant at install time, and we are
 going to make that disapper too, for users, but the documentation is
 intheir face all the darned time. You should be way more pissed about
 the documentation emntioning the unmentionable software out there!!

So, this is like the untouchables issue in India. I am amused.

manoj
-- 
 Christmas: A day set apart by some as a time for turkey, presents,
 cranberry salads, family get-togethers; for others, noted as having
 the best response time of the entire year.
Manoj Srivastava   <[EMAIL PROTECTED]>  
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

[Manoj Srivastava]

Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:

 Raul> And the point is: we are supposed to support non-free packages, we're
 Raul> not supposed to make them a part of debian.

A suggests is not making it part of Debian, espescially if the
 user interface tools are modified not to show it.

Logis suggests that referring to something does not make that
 something else part of one. It it were so, all web pages with
 hyperlinks wouyld have copyright issues.

And I would love to get royalties by refering to something
 stienbeck wrote in an article I write, and hence make it part
 of my article (see how ridiculous it sounds?)

 Raul> Non-free packages aren't debian packages -- even if we've graciously
 Raul> decided to distribute them from our ftp sites.

 Raul> I think a lot of people have lost sight of this.

I cveretainly haven't. But I also think that Debian packages
 have a rigfht to refer to the big wide world out there that is not
 Debian. Heck, my packages refer to me, and I am *not* debian/main.

I do have a point here, all facetiousness aside.

manoj
-- 
 Awright, which one of you hid my PENIS ENVY?
Manoj Srivastava   <[EMAIL PROTECTED]>  
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

[Manoj Srivastava]

>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:

 Raul> What about that perl one liner?  Or just plain old dpkg -s?  Or vi
 Raul> /var/lib/dpkg/status?  Or, apt-cache dumpavail?  Or future simple 
programs
 Raul> of various sorts?

dpkg and apt-cache could be modified to respect any reference
 to missing/undesirable heirarchies with a little work.

And the idea is to non impose non-free software on people who
 do not want it, not project the fantasy that it does not exist. 

 Raul> Perhaps the suggestion is that we put something into policy to restrict
 Raul> the handling of these cases?

So we are into censorship now? No one mentions any non-free
 software in any package structure? I strongly object to this. Surely
 fee software is strong enough to stand on its own withourt having to
 resort to tactics like this? 

If you think it is not strong enough to do so, maybe you
 should examine your beliefs in the value of fee software.

manoj
-- 
 Lack of capability is usually disguised by lack of interest.
Manoj Srivastava   <[EMAIL PROTECTED]>  
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

[Manoj Srivastava]

>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:

 Raul> non-us/main is very different from non-free.  The first consists of
 Raul> DFSG software with temporary and/or localized distribution problems.
 Raul> The second consists of non-DFSG software.

Yes, I am aware of the obvious difference. However, for a user
 installing off a CD of the official CD image, they have a
 commonality: both represent a heirarchy that is not currently
 available, and there may be other reasons for not using the missing
 heirarchies (I had to ask permisson at work before I could use
 OpenSSH, for example).

I did not think I had to drive this point home.

 Raul> And it buys us a clean separation between the DFSG and non-DFSG
 Raul> parts of the system.

Im my opinion a suggestion offered by the package that is
 effectively ignored by the package management system on demand (or
 even by default), is a perfectly clean separation. None of the nasty
 bytes may be poresent on ones machine unless one so desires.

 Raul> Personally, I think that hard-coding into a DFSG package a reference
 Raul> to some non-DFSG package is rather grotesque.  I'm disappointed that
 Raul> we disagree on this issue.

Personally, I find ignorig the non-free packages akin to
 buring ones head in the sand. They exist out there. They make  work better. Pretneding they do not exist is, umm, well, I'd
 rather not say.

 >> Concentrating on the non-free in exclusion to the non-US is
 >> putting the religious issue in front of technical ones; that's just
 >> one thing that bothers me about this proposal. So far, Debian has
 >> always been about excellence, not about fanaticism.

 Raul> The distinction being?

 Raul> Excellence has always been a matter of opinion -- informed, experienced,
 Raul> opinion, but opinion nonetheless.

 Raul> You're labelling DFSG issues as religion, and offering in its place
 Raul> status quo.

I must object to this mischaracterization. I am not asking for
 status quo -- I am asking for our package management sytem,
 frontends to be enhanced with the ability to mask certain heirarchies
 -- whether they are undesired, or merely unavailable. This is
certainly not a status quo.

 Raul> But you're not thinking about the changes which are going to
 Raul> happen as Linux (and Debian) become more popular, and are
 Raul> adopted by large commercial interests.

I am. I am also thinking of users. I have come in recent
 contact with a large number of Linux afficianados at my new job, and
 while they like Linux, they are nowhere near as sold on the fanatical
 adherence to free software only as most debian developers are. 

I suspect that that is a more likely model for our user base
 than a GNU, umm, adherent. 

 Raul> Right now, we have a tradition of putting contrib on our
 Raul> official disk set.  Which is fine.  But we also have a
 Raul> tradition of >>not allowing a disk set which consists of DFSG
 Raul> only software to be called official<<.

 Raul> You call that technical excellence?  You call a course which
 Raul> would allow deviation from this tradition fanaticism?

Yes, and yes. 

 Raul> Why?

I would rather, in the spririt of the social contract, look at
 the user base, with the empasis being on free software, but being
 realistic enough to acknowledge what our users are.

The solution posited here of letting the packaging system
 allow users to have a fully free system and not see any references to
 non-free software, and letting this be the default, should address
 most of the we shall have a free system issue.

However, letting our other users opt to have non-fee software
 equally is following the socal contract.

But mostly I am against coercing dependencies to fit our
 preferences, rather than follow what the natural dictates of the
 relationship are.

 Raul> I think that's much better than creating a "Maybe-Suggests:"
 Raul> and stuffing non-free references into the DFSG packages.

If the relationship exists, and is real, that is the only
 right thing to do. And letting the packaging system listen to the
 users dictates means that users wanting only a free system shall see
 no difference.

 >> 
 >> If the references are never displayed *to people who dio not
 >> want* tham, why is that so bad? And why are we going through hoops to
 >> impose the religion on everyone else as well?

 Raul> What do you mean by "display"?  You want to chain people to dselect?

This is unworthy of you. I never mentioned dselect, though it
 is currently the official (and only) user interface to package
 selection, This would equally apply to any descendant or alternate.

I have gotten used to using apt-cache search , or dpkg
 -s, to look at package descriptions. Both could follow do not display
 missing/undesirable heirarchies directives to massage the display
 (this could take a little work, but so would anything to impleme

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

[Chris Waters]

Raul Miller <[EMAIL PROTECTED]> writes:

> On Fri, Dec 03, 1999 at 12:19:57AM -0800, Chris Waters wrote:
> > Chris Waters <[EMAIL PROTECTED]> writes:
> > > The other objection I've seen is, basically, "the purity of the system
> > > is marred by the very presence of even the *names* of non-free
> > > packages."  My opinion of this notion is unprintable.  :-)

> > I can't think of anything to add to that.  Except to comment that it
> > might be rather difficult to document samba if you could never refer
> > to non-free software.  :-)

> You're suggesting you don't recognize the difference between package
> structure and documentation?

The fact that I have already moved any non-free suggests in my
packages to the package description (even though I didn't have to)
should demonstrate that I am quite conversant with the difference.
However, what Manoj, Knghtbrd, I and others have been suggesting would
effectively make non-free suggests into no more than documentation for
people who don't configure their system to see non-free software.

In point of cold fact, with a weak-suggests, or with suggests modified
to do nothing for unavailable packages, the names of non-free packages
would be *less* visible, at least for my packages, because the
depends/suggests fields aren't shown by default in dselect, while the
description is.  Thus, both the free software fanatics and the
don't-care non-free software users would benefit.  I think that's what
they call a Big Win.  :-)

cheers
-- 
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: Submitting bugs ? (Was: Getting rid of section "base" ?)

[Chris Waters]

Joey Hess <[EMAIL PROTECTED]> writes:

> | 2.3.6. The base system 
>   --

> |
> |   The base system is a minimum subset of the Debian GNU/Linux system that is
> installed before everything else on a new system.  Thus, only very few 
> |   packages are allowed to go into the base system to keep the
> |   required disk usage very small.

> Most of these packages should have the priority value `required' or at
> least `important', 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 considered making some change to say that debian-boot has control of what
> goes in there, but I don't think that's really necessary. 

"You must not place..." implies that you can, but if the boot-floppy
people are doing manual selection, I don't see how you can.  I'd
strike that third paragraph completely.  Unless it's aimed at the
boot-floppy people, and I'd hope that we'd grant them reasonable
discretion.

Or am I missing something here?

Anyway, aside from that, it looks like a good proposal.

cheers
-- 
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.

a nitpicky reading of policy

[Joey Hess]

I read through the policy document today, trying to nitpick and find things
that have changed in current practice. Here's what I found:

* The policy manual uses the term "section" to refer to main, non-us,
  non-free, and contrib. This overloads the term since we typically call
  games, libs, docs, etc, sections. Instead, it calls those things
  subsections. It also uses the term inconsitently:
  
The packages in all the sections (_main_, _contrib_, _non-US/main_,
_non-free_, _non-US/contrib_, and _non-US/non-free_) are grouped   
further into _subsections_ to simplify handling.
  ^^^
The section for each package is specified in the package's _control
^^^
record_. However, the maintainer of the Debian archive may override   
this selection to assure the consistency of the Debian distribution.
 ^
Please check the current Debian distribution to see which sections are 
  
available.
...
The packages included in the `base' section have a special function.
   ^^^
   
  I think this deserves to be cleaned up, but I don't really know what to
  call main, contrib, and non-free. Distributions, maybe?

* The definition of the standard priority says it includes:

and a reasonable 
subset of TeX and LaTeX (if this is possible without X).

  Which implies that X is not standard. However, xlib6g and xfree86-common
  are standard. I think the text in the parens should be removed.

* "Every package must have exactly one maintainer at a time." This statement
   is violated by so many packages (including dpkg) that it should be removed.

* This seems self-contradictory. Are you supposed to remove the created
  directories or not?

However, the package should create empty directories below
`/usr/local' so that the system administrator knows where to place
site-specific files.  These directories should be removed on package   
removal if they are empty.

Note, that this applies only to directories _below_ `/usr/local', not  
_in_ `/usr/local'.  The directory `/usr/local' itself may only contain 
the sub-directories listed in FHS, section 4.6.  However, you may 
create directories below them as you wish.  You may not remove any of  
the directories listed in 4.6, even if you created them.

* Lines 1076 and 1177 of policy.text.gz should be indented by another tab.
  (This problem is not unique to the text version.)

* "Please look very careful at the details." s/careful/carefully/

* "file ftp.debian.org in /debian/doc/package-developer/menu-policy.txt"
  Actually, the file ends in .gz.

* "The Debian `menu' packages provides" There is only one menu package, so
   s/packages/package/

* "ftp.debian.org in /debian/doc/package-developer/mime_policy.txt"
  Actually, the file name is mime_policy.text.gz

* "Any scripts which create files in world-writable directories (e.g., in 
  `/tmp') have to use a mechanism which will fail if a file with the
  same name already exists." I can write code that complies with this and is
  still a serious security problem -- the problem is that this sentance
  encourages the naive to write something like:
if [ ! -e /tmp/foo ]; then
echo "goodbye, /etc/passwd" >/tmp/foo
fi
  Which is vunerable to a race. I think it's be better to require that 
  it use a "mechanism which will atomically fail ..."

* "If your packages creates or uses configuration files outside of
   `/etc', and it is not feasible to modify the package to use the
   `/etc', you should still put the files in /etc' and create symbolic 
   links to those files from the location that the package requires."
   
   "Use the `/etc'" sounds a little weird to me, perhaps s/the//

*  "must not overwrite or otherwise mangle the user's 
configuration without asking, must not ask unnecessary questions 
(particularly during upgrades), and otherwise be good citizens."

   Just to remove the tiny shred of ambiguity from this sentance, I'd say
   change the end to "and must otherwise be ..."

* "Do not arrange that the system administrator can only reconfigure the
   package to correspond to their local security policy by changing the
   permissions on a binary.  Ordinary files installed by `dpkg' (as opposed to
   conffiles and other similar objects) have their permissions reset to the
   distributed permissions when the package is reinstalled. Instead you should
   consider (for example) creating a group for people allowed to use the
   program(s) and making any setuid executables executable only by that group."

  This paragraph seems to be unaware of suidregister. Perhaps it should
  mention it as an alternative.

* "where ' is one of the following: