[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dak now supports ~ in version numbers



On Wed, Aug 09, 2006 at 11:48:16AM -0500, Manoj Srivastava wrote:
> On Wed, 9 Aug 2006 13:25:28 -0300, Henrique de Moraes Holschuh <hmh@debian.org> said: 
> 
> > On Wed, 09 Aug 2006, sean finney wrote:
> >> > > Thanks to the work of our DPL Anthony "aj" Towns (and all the
> >> > > other people who have worked on this without my knowledge), I
> >> > > am happy to announce that dak, our archive management software,
> >> > > finally supports the use of the tilde ('~') in version numbers.
> >> > 
> >> > Should we really start using this feature even though it violates
> >> > section 5.6.12 of the Policy?
> 
>         Quite often, advances in packaging lead policy, which tends to
>  be conservative, and wait to see  whether changes are correct, and to
>  allow time for flaws to be detected and corrected.  With this
>  understanding, it is perfectly OK to lead the policy document with
>  innovation -- and trust the release managers to not hold that these
>  chages are actually serious, or even bugs at all.
> 
> 
> >> i'd say we should update the policy document.
> 
> > Policy documents reality, so if now the reality is that ~ is
> > supported and its use is encouraged, then yes, policy should be
> > changed ASAP.
> 
>         No. Policy documents what is correct, not just any old broken
>  thing that is currently being done (not that that is the case here).
> 
>         In this case, ~ provides a mechanism to easily package
>  pre-release versions, so it is a good thing, it has been in place for
>  a long time, the semantics are fairly well set, it has been tested
>  across the whole suite of packaging tools, so yes, now  policy should
>  document it.
> 

Implementing something not required by policy should precede and lead
policy.

Using a formally non-permitted interface amongst a very closed set of
cooperating packages may precede policy if it is unlikely to cause breakage
in unsuspecting packages or end user/sysadmin scripts.

But where policy requires packages to follow some rule upon which other
packages or end users/sysadmins may be relying, such a change should at
least be discussed on debian-policy and preferably even added as a may
clause in policy before going ahead.

For this particular change, it broke a security filter in a private mirror
script which was there to protect me against dangerous chars (such as
linefeeds, spaces, ../../ escapes etc.) occurring in package files being
downloaded.  The script followed the well-accepted security maxim of
explicitly listing the permitted characters and broke rather suddenly when,
without warning, package files containing '~' in their version part appeared
in unstable/main/*/Packages in the past few days.

This was quite surprising and after diligently checking both my own copy of
policy, the HTML version on w.d.o/doc/debian-policy all the debian-policy
messages that arrived in my inbox from January 2005 until my last fetchmail
run less than a week ago found no mention either, so I started filing bugs
against the two packages then in the archive.  Only when a rerun of the
mirror script turned up two more packages did I realize that a rushed change
of policy might be in progress and reran fetchmail to find a swift reply and
these few message on debian-policy.

I am sorry for filing a bug against the first package to use the new
unofficial policy change, but rather annoyed that this change was not at
least mentioned somewhere policy-related well ahead of letting such files
loose outside experimental.  I have not checked all relevant packages, but
note that an amazingly large number of packages process files, file names or
other data containing Debian version numbers and wonder if all those tools
are compatible with the change and dak really being the last program to
change.

I hope someone has gone to the trouble of checking for compatibility in all
of the following places:

 - dpkg, apt and dak (obviously).

 - dpkg-search, apt-listchanges, dpkg-awk, lintian, linda, debhelper and all
  the other supplemental package handling tools.

 - synaptic, aptitude, kpkg and all the other dpkg front ends
 
 - apt-proxy, apt-cacher, debmirror and all the other tools that mirror or
  proxy the whole archive.

 - the mirroring scripts and httpd/ftpd/rsyncd configurations used by all
  the Debian mirrors.

 - the default behaviour of all the httpd/ftpd/rsyncd implementations
  packaged by Debian.


 - the versions of all of the above shipped in stable (since people may
  reasonably prefer to use stable tools to mirror/process/etc. the whole
  archive).

Now I will go ahead and change my own local admin scripts!

Jakob

-- 
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.



Reply to: