headers
Erich Schubert | 1 Oct 2002 01:00
Picon
Favicon

RFC: some new deb package flag: "upgrade-conflicts"

Maybe this has been discussed before, but the idea just came to me...

Based on that discussion about bogofilter:
Debian wants to provide a clean upgrade path for all packages.
But sometimes this is not possible (because it would require modifying
the users' home directories and such stuff)
Maybe it could be useful to have some kind of "upgrade-conflict" of
packages - these packages shouldn't be upgraded automatically, and
should probably be given the possibility for displaying a debconf note.

It could have been useful for galeon1, too - during it's early stages
(like version 0.1x) upgrades often required that you remove your .galeon
directory. This was "solved" by showing a debconf note when an upgrade
from such a version was detected; but for bogofilter it seems like it
actually does harm (and not just break some alpha version browser...)
if it get's blindly upgraded - a note should be displayed to the
administrator (which then could tell him to make sure all his users know
about the upgrade, and disable stuff like bogofilter during the upgrade)

Having this as an separate package version flag could allow to detect
such problems at early stages. Maybe even allow the packages to be
upgrade in two stages: upgrade the oldstable package to the stable
version (containing upgrade scripts from oldstable) and then on to
unstable (containing only upgrade scripts for current stable).

Like
oldstable   foobar  Version 0.1
stable      foobar  Version 1.1
unstable    foobar  Version 2.1     Upgrade-Conflicts: foobar <= 1.0
(Continue reading)

Permalink | Reply | 43 comments |
headers
Erich Schubert | 1 Oct 2002 01:02
Picon
Favicon

Re: attn: bogofilter users

> And Pre-Depend on debconf until the end of time?

Dropping a debconf upgrade note for a version that was only in unstable
when the new version is (or is almost ;) in stable is fine, IMHO.
Anyone using package version from unstable can be expected to upgrade at
least every few months (and at least to newer stable releases)
Or he must risk that stuff breaks.

I would have to look at galeon's changelog when i dropped the debconf
note for < 1.0 upgrades. I think about version 1.2.3

Greetings,
Erich

--

-- 
        erich <at> (mucl.de|debian.org)        --        GPG Key ID: 4B3A135C
     A man doesn't know what he knows until he knows what he doesn't know.
            Ein Freund ist ein Geschenk, das man sich selbst macht.
               Humor sollte immmer dabeisein, auch bei Problemen.
Permalink | Reply | 0 comments |
headers
Simon Richter | 1 Oct 2002 01:38
Picon
Favicon

Re: RFC: some new deb package flag: "upgrade-conflicts"

Erich,

> Debian wants to provide a clean upgrade path for all packages.
> But sometimes this is not possible (because it would require modifying
> the users' home directories and such stuff)
> Maybe it could be useful to have some kind of "upgrade-conflict" of
> packages - these packages shouldn't be upgraded automatically, and
> should probably be given the possibility for displaying a debconf note.

Debian packages are expected to be upgradeable with skipping one
release. After that, behaviour is officially undefined (but leaving the
upgrade path in the postinst doesn't harm in most cases). So what you're
proposing is in fact there, but not formalized for the package manager.

There are a few approaches to problems like these:

 - Ask the administrator in the config script whether she allows
   upgrading of users' config files, then do it in the postinst.
 - Provide a wrapper that asks the user whether she wants to upgrade her
   config files
 - Hack the source so that old-style configs can be read in (issuing a
   warning)
 - Hack the source so that an old-style config is ignored (issuing a
   warning)

Number one is most admin friendly, yet if the package maintainer screws
up, she has lots of users screaming at her. Number two obviously works
only for interactive programs and sometimes degrades performance, but is
the best approach IMO. For the mail filter, the best idea IMO would be a
mixture of 3 and 4 (ignore everything that can be rebuilt, try to
(Continue reading)

Permalink | Reply | 42 comments |
headers
Joey Hess | 1 Oct 2002 02:01
Picon
Favicon
Gravatar

Re: attn: bogofilter users

Clint Adams wrote:
> > Even in unstable, I would be rather upset if a maintainer knowingly
> > broke people's setups without any warning from the package during the
> > upgrade. A debconf alert during preinst seems like the right solution.
> 
> And Pre-Depend on debconf until the end of time?

Only if you're using debconf in your preinst for some reason.

preinst => pre-depend
postinst => depend

--

-- 
see shy jo
Permalink | Reply | 1 comment |
headers
Sean 'Shaleh' Perry | 1 Oct 2002 01:59
Picon

Re: attn: bogofilter users

On Monday 30 September 2002 17:01, Joey Hess wrote:
> Clint Adams wrote:
> > > Even in unstable, I would be rather upset if a maintainer knowingly
> > > broke people's setups without any warning from the package during the
> > > upgrade. A debconf alert during preinst seems like the right solution.
> >
> > And Pre-Depend on debconf until the end of time?
>
> Only if you're using debconf in your preinst for some reason.
>
> preinst => pre-depend
> postinst => depend

which they would be because if the package installs bad things happen ....
Permalink | Reply | 0 comments |
headers
Brian May | 1 Oct 2002 03:10
Picon
Picon

Re: dpkg-statoverride question

On Mon, Sep 30, 2002 at 05:43:09PM +0100, Julian Gilbey wrote:
> This is weird.

Yes.

Hows this:

*** amavisd.conf (Y/I/N/O/D/Z) [default=N] ? n
adduser: Warning: The home dir you specified already exists.
User amavis does already exist. Exiting...
Output of initial dpkg-statoverride --list /var/lib/amavis:
dpkg: error processing amavis-postfix (--install):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 amavis-postfix

Oh, wait; while it indicates that the override isn't there, I don't
think thats what you intended, I will change that. (append "|| true" at
the end of the line).

Here is the output:

scrooge:/tmp/bam/012_sharedlibs/heimdal-0.5# dpkg-statoverride --list /var/run/amavis
amavis root 755 /var/run/amavis
scrooge:/tmp/bam/012_sharedlibs/heimdal-0.5# se_dpkg -i
/home/bam/source/debian/amavis/amavis-postfix_20020517-21_i386.deb 
Authenticating bam.
Password: 
(Reading database ... 105741 files and directories currently installed.)
Preparing to replace amavis-postfix 20020517-21 (using
(Continue reading)

Permalink | Reply | 4 comments |
headers
Brian May | 1 Oct 2002 03:18
Picon
Picon

Re: pbuilder automation

On Mon, Sep 30, 2002 at 02:16:01PM -0700, Jeremy T. Bouse wrote:
> 	Actually I have a script that does a CVS checkout from the
> upstreams CVS repository and creates the upstream tarball... Then it
> creates the package-version directory and copies the tarball and debian/
> stuff over runs through dpkg-source to build the package then updates
> the pbuilder unstable base.tgz and finally builds... Once built I have
> it upload to people.d.o and update the Packages.gz file so I can test it
> on my machines by installing through apt-get... Works rather nice and it
> almost automatically handles upstream revision changes as well... Makes
> it really easy to upload the official packages once the code is released
> as a new version as I've been building nitely from CVS...

Sounds good.

Can I please have a copy?
--

-- 
Brian May <bam <at> snoopy.apana.org.au>
Permalink | Reply | 1 comment |
headers
Brian May | 1 Oct 2002 03:31
Picon
Favicon

Re: pbuilder automation

On Mon, Sep 30, 2002 at 08:28:57AM +0200, Ola Lundqvist wrote:
> If you wait a couple of months you may have what you are
> looking for (with a lot of extra things to be able to upload
> to different locations, etc).

Sounds great!

> But you probably do not want to wait that long.

I can be patient, I swear!

Now hurry up, stop wasting time reading this E-Mail,
and get on with it ;-).
--

-- 
Brian May <bam <at> debian.org>
Permalink | Reply | 1 comment |
headers
Brian May | 1 Oct 2002 03:34
Picon
Favicon

Re: SANE packages unmaintained : intent to take over

On Mon, Sep 30, 2002 at 02:30:36AM -0400, Joseph Fannin wrote:
>     I've used this backend before -- it works well for me.  People
> with higher standards than me might have something to say about the
> image quality that I miss, but it works.  The patch against the SANE
> source tree seems minimally invasive at a glance.

Strange. I heard reports on debian-user that results were poor,
the colors were badly distorted or something.

Does the kernel source still need to be changed for it to work?
--

-- 
Brian May <bam <at> debian.org>
Permalink | Reply | 1 comment |
headers
Jeremy T. Bouse | 1 Oct 2002 03:49
Picon
Favicon

Re: pbuilder automation

	Let me get the scripts together and I'll try and get them sent
to you this week... Just got done with a convention this weekend so I'm
beat and taking some time to relax... The one script is pretty much
customized for this project but should be able to be used to get you
going...

	Jeremy

On Tue, Oct 01, 2002 at 11:18:14AM +1000, Brian May wrote:
> Sounds good.
> 
> Can I please have a copy?
> -- 
> Brian May <bam <at> snoopy.apana.org.au>
>
Permalink | Reply | 0 comments |

Gmane