Policy 3.1.0.0 uploaded

[Julian Gilbey]

I have just uploaded debian-policy and packaging-manual version
3.1.0.0 to master, so the main packages should be installed in the
next dinstall run.  This version of policy takes account of the Tech
Committee decision on the FHS and a large number of other outstanding
issues.  A few are still to be incorporated into the next version of
policy, but here we are

Below you will find the relevant portions of the upgrading checklist
for policy versions 3.0.0.0 through to 3.1.0.0.  This will affect
almost all packages, so please do have a look at the list.

   Julian

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

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer,  see http://www.debian.org/~jdg


3.1.0.0Oct 99

  Policy Manual:
 - /usr/doc/ has to be a symlink pointing to
   /usr/share/doc/.  This symlink has to be
   maintained by postinst and prerm, because dpkg will cause
   problems otherwise.  Create/remote the symlinks using debhelper
   or see section "6.4. Accessing the documentation" for more
   information.
 - Introduced source dependencies.  (Whereas this ought to demand a
   major policy number rise, we've only just had one of them, so
   I'm going to use a minor number instead.)
 - /etc/rc.boot has been deprecated in favour of /etc/rcS.d.
   Packages should not be touching this directory, anyway, but
   should use update-rc.d instead.
 - update-rc.d is now the *only* allowable way of accessing the
   /etc/rc?.d/[SK]??* links.  Any scripts which manipulate them
   directly must be changed to use update-rc.d instead.  (This is
   because the file-rc package handles this information in an
   incompatible way.)
 - Compiled examples go in /usr/lib//examples with
   symlinks from /usr/share/doc//examples/* or from
   /usr/share/doc//examples itself.
 - Updated FHS to a 2.1 draft; this reverts /var/state to
  /var/lib.
 - Added MIME sub-policy document.
 - VISUAL is allowed as a (higher priority) alternative to EDITOR.
 - Modified liblockfile description, which affects
   mailbox-accessing programs.  Please see the policy document for
   details.
 - If a package provides a changelog in HTML format, a text-only
   version should also be included.  Such a version may be prepared
   using lynx -dump -nolist.)

  Packaging Manual:
 - Description of how to handle version numbers based on dates
   added: see section 5.1.


3.0.1.0Jul 99

  Policy Manual:
-  Added the clarification that the .la files are essential for the
   packages using libtool's libltdl library, in which case the
   .la files must go in the run-time library package.


3.0.0.0Jun 99

  Policy Manual:
- Debian formally moves from the FSSTND to the FHS. This is a
  major change, and the implications of this move are probably
  not all known.
- Only 3 digits of the Standards version need be included in
  control files, though all four digits are still permitted. 
- The location of the GPL has changed to
  /usr/share/common-licenses. This may require changing the
  copyright files to point to the correct location of the GPL and
  other major licences
- Packages that use libtool to create shared libraries must
  include the .la files in the -dev packages.
- Use logrotate to rotate log files
- section 5.8 has been rewritten (Programs for the X Window
  System) 
- There is now anassi=ociated menu policy, in a separate document,
  that carries the full weight of Debian policy. 
- The files `/var/run/utmp', `/var/log/wtmp' and
  `/var/log/lastlog' must be installed writeable by group
  utmp. Programs who need to modify those files must be installed
  install setgid utmp.

Re: FWD: dh_compress

[Joey Hess]

Massimo Dal Zotto wrote:
> The default ext2 blocksize is 1k and very few people change it.

That's not so. I've looked at the source to mke2fs and experimented and the
default size varies between 1k and 4k, depending on the size of the partition.
1 GB partitions get 4k blocks, 100 mb partitions, 1k blocks.

> I propose therefore that the the minimum size candidate for compression is
> the minimum filesystem blocksize + 1 byte.

Logically, this should be + 1 bit.

> I would personally like that also the copyright files would be compressed.
> I don't think that the compression changes the copyright itself or the
> licencing policy of the package, or the ability of the user to read this
> information. We must install anyway the package in a debian system to be
> able to read the docs and zless is already installed in every base system.

How do you plan to read a compressed copyright file for gzip to determine if
you agree with gzip's copyright and agree with it, to know if you can even
use gzip?

-- 
see shy jo

Re: FWD: dh_compress

[Joseph Carter]

On Thu, Nov 04, 1999 at 11:14:35AM +0100, Massimo Dal Zotto wrote:
> > 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...
> 
> I don't agree.
> 
> The default ext2 blocksize is 1k and very few people change it. So most of
> the filesystems around use this minimum blocksize.

mkext2fs defaulted to 4K blocks on my drives, but then I have _BIG_
partitions.


> If the goal of dh_compress is to save space we should try to compress any
> file greater than the minimum blocksize. If we store a 4k file compressed
> to 1k on a default 1k-block filesystem we can save 3k while if we store
> the same compressed file in a 4k-block filesystem we don't save any space
> but we also don't lose anything, except maybe a very small delay needed for
> decompressing the file, but this should be unnoticeable for a small file.

Understandable, I just don't think the savings is that significant, even
on a 1K block filesystem.  If you can show me an average system or two's
differences in filesize I might be more encouraged to agree with you, I
just don't think there are enough cases to be worth changing the current
game plan.


> I propose therefore that the the minimum size candidate for compression is
> the minimum filesystem blocksize + 1 byte.
> 
> I can agree that the total space saved by compressing all those small files
> can't be very much, maybe 50-100k, but is a question of principle. If we
> want to save disk space let's save all the possible space.

I can't reasonably believe you'll get even 50k on a system that's already
strapped for diskspace.  Plus I think we should consider the AVERAGE
system (where I rate average as a low end Pentium which can be had for
next to nothing) for the general case.  There are ext2 disk compression
drivers which do a much better job of what you describe using the same
technologies--transparently.


> I would personally like that also the copyright files would be compressed.
> I don't think that the compression changes the copyright itself or the
> licencing policy of the package, or the ability of the user to read this
> information. We must install anyway the 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 typing an extra z before
the less, however I'd more rather never hear the argument that we're at
all obscuring Copyright information.

-- 
- Joseph Carter GnuPG public key:   1024D/DCF9DAB3, 2048g/3F9C2A43
- [EMAIL PROTECTED]   20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
--
 anyone seen my 80 column card?



pgpxOOLphMgRu.pgp
Description: PGP signature

Re: FWD: dh_compress

[Drake Diedrich]

On Thu, Nov 04, 1999 at 05:05:04PM -0800, Joey Hess wrote:
> 
> How do you plan to read a compressed copyright file for gzip to determine if
> you agree with gzip's copyright and agree with it, to know if you can even
> use gzip?
> 

   How are you going to get the copyright out of a .deb or base.tar.gz in
the first place without using gzip?  For that matter uncompressed copyright
files are a lot easier to read using a GPL'd ext2 filesystem driver than
hunting for the right disk sectors on a raw partition.

Re: FWD: dh_compress

[Manoj Srivastava]

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

 Joey> Policy says that "small" files should be compressed, but does
 Joey> not define small. The default blocksize seems like a good
 Joey> definition. What is the default blocksize? 1k? 4k? Variable? I
 Joey> have heard all three answers.

If I recall the discussion that went on before that was
 included in policy correctly, we decided to let that be the decision
 of the developer (there is something to be said about allowing the
 developer some leeway ;-).

I personally tend to use 4k, on the average.

manoj
-- 
 Writing is easy; all you do is sit staring at the blank sheet of
 paper until drops of blood form on your forehead. Gene Fowler
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C fingerprint = 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C