Handling of removed packages

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Handling of removed packages

Marc 'HE' Brockschmidt-3
Heya,

For some time now, I have been thinking about the problem of packages
which are removed from the archive at some point, without an (enforced)
transition to a new package name. Users of such packages keep them
around, usually never noticing the fact that no security (or other)
support is available anymore.

Our current package management doesn't handle this case at all, so we
might need to fix this - we just need to decide how. The probably
easiest way would be to make apt whine on all packages that are not
available in any version at one of the locations specified in
sources.list. This trivial solution sucks, because locally created
packages [1] also fall in this category. So, has anyone a good idea
solving this problem, without needing to keepr masses of status/diff/bla
files around?

Marc

Footnotes:
[1]  Such as kernel packages, binary kernel modules built from sources
     available in the archive, local configuration packages, ...
--
BOFH #368:
Failure to adjust for daylight savings time.

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

Lucas Nussbaum
On 29/05/08 at 13:24 +0200, Marc 'HE' Brockschmidt wrote:

> Heya,
>
> For some time now, I have been thinking about the problem of packages
> which are removed from the archive at some point, without an (enforced)
> transition to a new package name. Users of such packages keep them
> around, usually never noticing the fact that no security (or other)
> support is available anymore.
>
> Our current package management doesn't handle this case at all, so we
> might need to fix this - we just need to decide how. The probably
> easiest way would be to make apt whine on all packages that are not
> available in any version at one of the locations specified in
> sources.list. This trivial solution sucks, because locally created
> packages [1] also fall in this category. So, has anyone a good idea
> solving this problem, without needing to keepr masses of status/diff/bla
> files around?
I usually run 'apt-show-versions | grep -v uptodate' to find them. The
remaining list is short enough to be analyzed manually.
--
| Lucas Nussbaum
| [hidden email]   http://www.lucas-nussbaum.net/ |
| jabber: [hidden email]             GPG: 1024D/023B3F4F |

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

Olivier Berger
In reply to this post by Marc 'HE' Brockschmidt-3
Le jeudi 29 mai 2008 à 13:24 +0200, Marc 'HE' Brockschmidt a écrit :
> Heya,
>
> For some time now, I have been thinking about the problem of packages
> which are removed from the archive at some point, without an (enforced)
> transition to a new package name. Users of such packages keep them
> around, usually never noticing the fact that no security (or other)
> support is available anymore.
>

Just for the records, there's a RSS feed about these :
http://ftp-master.debian.org/~joerg/removals/removals.rss

My 2 cents,

Best regards,
--
Olivier BERGER <[hidden email]> (*NEW ADDRESS*)
http://www-inf.it-sudparis.eu/~olberger/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM / TELECOM & Management SudParis (http://www.it-sudparis.eu/), Evry



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

Frans Pop-3
In reply to this post by Marc 'HE' Brockschmidt-3
/me seems to remember a fairly recent discussion about this...
Right: http://lists.debian.org/debian-devel/2008/03/msg00354.html

Marc 'HE' Brockschmidt wrote:
> Our current package management doesn't handle this case at all, so we

That is not entirely true: aptitude (and also dselect) does clearly display
obsolete and locally built packages in a separate category.
IMHO is any package management _frontend_ that does not do that in some way
(category, color, flag, ...) buggy [1]. Preferably they should also offer
some easily accessible help (especially graphical frontends).

Also, the Release Notes pay quite a lot of attention to this issue:
http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#s-obsolete

And there are special tools to find obsolete packages (see link above).

What is true is that the package management _command line tools_ do not
display any info about such packages.

> might need to fix this - we just need to decide how. The probably
> easiest way would be to make apt whine on all packages that are not
> available in any version at one of the locations specified in
> sources.list. This trivial solution sucks, because locally created
> packages [1] also fall in this category.

This would for me be unacceptable as it interferes too much with normal
work.

What could be an option is to have apt and aptitude display the number of
such packages in their summaries, preferably with an apt.conf option to
turn that off for people who do check for such packages by other means.

Cheers,
FJP

[1] Maybe we should define a minimum set of features a package management
_frontend_ must have before it may advertise itself as no longer alpha or
beta quality?

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

Stefano Zacchiroli
In reply to this post by Marc 'HE' Brockschmidt-3
On Thu, May 29, 2008 at 01:24:59PM +0200, Marc 'HE' Brockschmidt wrote:
> The probably easiest way would be to make apt whine on all packages
> that are not available in any version at one of the locations
> specified in sources.list. This trivial solution sucks, because
> locally created packages [1] also fall in this category.

Thinking at why this solutions sucks (it does), it occurred to me that
the reason is we don't have a ready to use easy way to let our users
install packages "properly", that is: only via entries in sources.list.
This is way they^W are using "dpkg -i".

So, instead of looking for an alternative twisted solution, why we don't
fix this problem?

It looks like it would be enough to:

- add a pre-defined entry in the legacy /etc/apt/sources.list pointing
  to file:///some/where/

- (optional) provide a trivial helper script which takes as input a set
  of .deb or .dsc and installs them in /some/where/, invoking
  dpkg-scan{package,source}s as needed (getting

- (even more optional) wrap into a single command the above + an
  invocation of apt-get to install the just installed package(s)

I'm convinced that using apt entries is the way to go for installing
local packages, but out of the box it is just not convenient enough to
do that.

Comments?

--
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?    /\    All one has to do is hit the
(15:57:15)  Bac: no, la demo scema    \/    right keys at the right time

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

debian (Bugzilla)
In reply to this post by Marc 'HE' Brockschmidt-3
Hello,
Marc 'HE' Brockschmidt schrieb:
> For some time now, I have been thinking about the problem of packages
> which are removed from the archive at some point, without an (enforced)
> transition to a new package name. Users of such packages keep them
> around, usually never noticing the fact that no security (or other)
> support is available anymore.

I have somewhat of a deja-vù here with that thread. When I remember correctly
just about the beginning of this year there was a discussion about how to
find/remove/manage obsolete packages either here on -devel or on -mentors. The
aptitude-way Frans pointed out was mentioned there too (maybe by Frans, I can't
recall). So the solution then was "the user must check aptitudes obsolete
category". And for me that is enough, though a automatic notification by
aptitude, when a package is added to that category would be nice.

Kind regards,
Kai

P.S.: This e-mail is just a "reminder", that this was already discussed, but I
have right now no time to search the archives. But eventually it helps to avoid
reiterating all pros and cons.



--

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: [hidden email]
Jabber (debianforum.de): Drizzt
URL: http://wiki.debianforum.de/Drizzt_Do%27Urden
GnuPG: 0xE1DE59D2      0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2
(http://pgpkeys.pca.dfn.de/pks/lookup?search=0xE1DE59D2&fingerprint=on&hash=on&op=vindex)


signature.asc (666 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

Marc 'HE' Brockschmidt-3
In reply to this post by Lucas Nussbaum
Lucas Nussbaum <[hidden email]> writes:

> On 29/05/08 at 13:24 +0200, Marc 'HE' Brockschmidt wrote:
>> For some time now, I have been thinking about the problem of packages
>> which are removed from the archive at some point, without an (enforced)
>> transition to a new package name. Users of such packages keep them
>> around, usually never noticing the fact that no security (or other)
>> support is available anymore.
>>
>> Our current package management doesn't handle this case at all, so we
>> might need to fix this - we just need to decide how. The probably
>> easiest way would be to make apt whine on all packages that are not
>> available in any version at one of the locations specified in
>> sources.list. This trivial solution sucks, because locally created
>> packages [1] also fall in this category. So, has anyone a good idea
>> solving this problem, without needing to keepr masses of status/diff/bla
>> files around?
> I usually run 'apt-show-versions | grep -v uptodate' to find them. The
> remaining list is short enough to be analyzed manually.
I don't think normal users do that - and users shouldn't expect to
install Priority: optional packages to get a list of things that are not
supported anymore by their distribution.

Marc
--
BOFH #244:
Your cat tried to eat the mouse.

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

Ron Johnson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/29/08 08:01, Marc 'HE' Brockschmidt wrote:

> Lucas Nussbaum <[hidden email]> writes:
>> On 29/05/08 at 13:24 +0200, Marc 'HE' Brockschmidt wrote:
>>> For some time now, I have been thinking about the problem of packages
>>> which are removed from the archive at some point, without an (enforced)
>>> transition to a new package name. Users of such packages keep them
>>> around, usually never noticing the fact that no security (or other)
>>> support is available anymore.
>>>
>>> Our current package management doesn't handle this case at all, so we
>>> might need to fix this - we just need to decide how. The probably
>>> easiest way would be to make apt whine on all packages that are not
>>> available in any version at one of the locations specified in
>>> sources.list. This trivial solution sucks, because locally created
>>> packages [1] also fall in this category. So, has anyone a good idea
>>> solving this problem, without needing to keepr masses of status/diff/bla
>>> files around?
>> I usually run 'apt-show-versions | grep -v uptodate' to find them. The
>> remaining list is short enough to be analyzed manually.
>
> I don't think normal users do that - and users shouldn't expect to
> install Priority: optional packages to get a list of things that are not
> supported anymore by their distribution.

Why not?  IOW, why shouldn't "normal users" be expected to expend a
little effort to maintain their system?

- --
Ron Johnson, Jr.
Jefferson LA  USA

"I must acknowledge, once and for all, that the purpose of
diplomacy is to prolong a crisis.", Mr. Spock
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIPq0ZS9HxQb37XmcRAuN5AKCAzmedJn+wnvFEsUuBwHqbKq71+gCgvZCU
lvZEWU+UH7B/R0hwsVDGjM8=
=tWcw
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

James McCoy
In reply to this post by debian (Bugzilla)
On Thu, May 29, 2008 at 02:40:07PM +0200, Kai Wasserbäch wrote:
> And for me that is enough, though a automatic notification by
> aptitude, when a package is added to that category would be nice.

As of version 0.4.11, this does happen.  From the NEWS file:

  * Command-line updates in aptitude will now list packages that are
    newly obsolete.  This doesn't work when a source is removed and
    all its packages become obsolete, for technical reasons.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

Marc 'HE' Brockschmidt-3
In reply to this post by Ron Johnson
Ron Johnson <[hidden email]> writes:
> On 05/29/08 08:01, Marc 'HE' Brockschmidt wrote:
>> Lucas Nussbaum <[hidden email]> writes:
>>> I usually run 'apt-show-versions | grep -v uptodate' to find them. The
>>> remaining list is short enough to be analyzed manually.
>> I don't think normal users do that - and users shouldn't expect to
>> install Priority: optional packages to get a list of things that are not
>> supported anymore by their distribution.
> Why not?  IOW, why shouldn't "normal users" be expected to expend a
> little effort to maintain their system?

Because this task can easily be automated. Forcing people to do things
manually that should be done by the package management sucks.

Marc
--
Fachbegriffe der Informatik - Einfach erklärt
35: Hacker
       Randal Schwartz (nach Intel)

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

Frans Pop-3
In reply to this post by James McCoy
James Vega wrote:
> As of version 0.4.11, this does happen.  From the NEWS file:
>   * Command-line updates in aptitude will now list packages that are
>     newly obsolete.  This doesn't work when a source is removed and
>     all its packages become obsolete, for technical reasons.

Hmm. New Debian release. User uses codenames in sources.list.

# sed -i "s/etch/lenny/" /etc/apt/sources.list
# aptitude update

Does this fit in the exception listed above? I would think yes and in that
case the only use case we really care about would not be supported.
Maybe I'm reading that wrong though or is "source" defined at a higher level
than I think it is.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

Adeodato Simó-4
In reply to this post by Stefano Zacchiroli
* Stefano Zacchiroli [Thu, 29 May 2008 14:18:35 +0200]:

> On Thu, May 29, 2008 at 01:24:59PM +0200, Marc 'HE' Brockschmidt wrote:
> > The probably easiest way would be to make apt whine on all packages
> > that are not available in any version at one of the locations
> > specified in sources.list. This trivial solution sucks, because
> > locally created packages [1] also fall in this category.

> Thinking at why this solutions sucks (it does), it occurred to me that
[snip bit about local packages management]

(In case it isn't obvious, even with dropping local packages from this
category, this solution would still suck, because the admin or user may
want to keep those packages installed, without having to see apt whine
at every invocation.)

Cheers,

--
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
Love in your heart wasn't put there to stay.
Love isn't love 'til you give it away.
                -- Oscar Hammerstein II


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

Steve Greenland
In reply to this post by Frans Pop-3
On 29-May-08, 07:07 (CDT), Frans Pop <[hidden email]> wrote:
> Marc 'HE' Brockschmidt wrote:
> > Our current package management doesn't handle this case at all, so we
>
> That is not entirely true: aptitude (and also dselect) does clearly display
> obsolete and locally built packages in a separate category.

Parsing error, I think.

Aptitude shows a group of "obsolete and locally created packages".
However, it doesn't distinguish between them, as far as I can tell,
which is what Marc (and I) would like.

Steve

--
Steve Greenland
    The irony is that Bill Gates claims to be making a stable operating
    system and Linus Torvalds claims to be trying to take over the
    world.       -- seen on the net


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

John H. Robinson, IV
Steve Greenland wrote:
>
> Aptitude shows a group of "obsolete and locally created packages".
> However, it doesn't distinguish between them, as far as I can tell,
> which is what Marc (and I) would like.

There really is no current way to do this. Case in point: if you use
wget and dpkg -i to install a package, it will still be in the Debian
Packages and thusly be tracked by the front ends.

If you create it locally, or via a -src or -installer, then it is the
same as the above but gets obsoleted.  ie: installed by hand, no record
of the package in Packages.

The solution to this that I see is a database similar to Packages, that
lists the package names along with 1) the last released version, 2)
all versions released, or 3) (my preferred) all versions released in the
last release made (ie: all versions in Sarge)

This way the front-ends can compare the installed version to the one(s)
listed in Obsoletes, and if there is a match, warn the user.


This allows the front-ends to ignore locally installed packages, and
those Obsolete packages that have been locally re-built.

It also forces yet another file that has to be downloaded by the back
ends, and parsed by the front ends.

I am willing to work on formats and debugging. I don't really want to
mess with apt* internals.

--
John H. Robinson, IV          [hidden email]
                                                                 http  ((((
WARNING: I cannot be held responsible for the above,         sbih.org ( )(:[
as apparently my cats have learned how to type.          spiders.html  ((((


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

Franklin PIAT
In reply to this post by Stefano Zacchiroli
CCing debian-dpkg for obvious reasons.

On Thu, 2008-05-29 at 14:18 +0200, Stefano Zacchiroli wrote:

> On Thu, May 29, 2008 at 01:24:59PM +0200, Marc 'HE' Brockschmidt wrote:
> > The probably easiest way would be to make apt whine on all packages
> > that are not available in any version at one of the locations
> > specified in sources.list. This trivial solution sucks, because
> > locally created packages [1] also fall in this category.
>
> Thinking at why this solutions sucks (it does), it occurred to me that
> the reason is we don't have a ready to use easy way to let our users
> install packages "properly", that is: only via entries in sources.list.
> This is way they^W are using "dpkg -i".

Using `dpkg -i` really is insane as far as security is concerned :
people install Acrobat, Opera, Flashplayer, w32codecs and others
manually, then simply forget about it.

I know that's exactly what people do in some proprietary operating
system but still, that's insane.

I suggest to modify dpkg so it refuse to install package, unless the
option "--insecure" is specified. Such option's manpage description
would be :

> dpkg --install --insecure package_file...
> The option --insecure is now mandatory to install a ".deb" package.
>
> Installing a ".deb" file manually is considered a bad practice (i.e
> insecure), because the package wouldn't be updated when the maintainer
> release a security update.
>
> Instead of downloading and installing a .deb file, you should declare
> it's apt repository. This is done by adding the package's repository
> to /etc/apt/sources.list or /etc/apt/sources.list.d/. See
> sources.list(5).

* This option would be an effective solution to educate new users.
* For the same reason, we should remove gdebi's "Install" button.

I suggest Proposed manpage improvement for this option :

Franklin



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

Mike Bird-2
On Thu May 29 2008 12:37:28 Franklin PIAT wrote:
> Using `dpkg -i` really is insane as far as security is concerned :

The above statement is false.

Many people do extra levels of testing before
rolling out updates with "dpkg -i".  With "apt-get"
you never know when the package lists will be updated.

--Mike Bird


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

Wolf Wiegand
In reply to this post by Marc 'HE' Brockschmidt-3
Hi,

Marc 'HE' Brockschmidt wrote:

> For some time now, I have been thinking about the problem of packages
> which are removed from the archive at some point, without an (enforced)
> transition to a new package name. Users of such packages keep them
> around, usually never noticing the fact that no security (or other)
> support is available anymore.

Maybe it should be mandatory to always have a transition package for
packages which are being removed from the archives? For example, when
package X_0.1 is to be removed from the archive, there has to be a
transition to a package X-obsoleted_0.1 (which is in fact the same as
X_0.1).

As addition, some mean of telling the user "There are $NUM installed
packages on your system that seem to be abandoned: X-obsoleted" could
be established (either in apt, aptitude, or apt-listchanges), with
the option to turn off this message (I wouldn't want to have to read
this every day).

> Our current package management doesn't handle this case at all, so we
> might need to fix this - we just need to decide how. The probably
> easiest way would be to make apt whine on all packages that are not
> available in any version at one of the locations specified in
> sources.list. This trivial solution sucks, because locally created
> packages [1] also fall in this category.

IMHO, packages that are not (and never have been) available from the
Debian archives should be left alone from any 'detect unsupported
packages'-mechanisms. The user decided to install these packages, so
he/she will have to deal with keeping them up to date or uninstall them
once they are not maintained anymore.

Cheers,

Wolf

--
I hope that when I die, people say about me, 'Boy, that guy sure owed me
a lot of money.' (Jack Handey)


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

Raphael Geissert
In reply to this post by Marc 'HE' Brockschmidt-3
Marc 'HE' Brockschmidt wrote:
>
> Our current package management doesn't handle this case at all, so we
> might need to fix this - we just need to decide how. The probably
> easiest way would be to make apt whine on all packages that are not
> available in any version at one of the locations specified in
> sources.list. This trivial solution sucks, because locally created
> packages [1] also fall in this category. So, has anyone a good idea
> solving this problem, without needing to keepr masses of status/diff/bla
> files around?

Not perfect, but one of the solutions I've found is a script I wrote:

> $ notAptable --help
> notAptable [--version] [--help] [-s/var/lib/dpkg/status]
[-aptf/path/to/aptavail/equiv/file]  [-aptx'apt-cache dumpavail']
[-ipackagename]
> List packages which are installed on the system  but are not known by apt.
> Options:
>         -s Path to file to use when grepping for installed packages
>         -aptf Path to file to use when grepping for the apt-able packages
>         -aptx Same as above but instead of being a file the specified
command is executed
>         -i Exclude a package that would otherwise be listed
> When not overriden by an option the default files/data is up to
grep-dctrl's defaults
> This script is said to report packages that were removed from the archive
> (except those listed in /home/raphael/.listNotAptable.ignore)
>
> Copyright 2008 by Raphael Geissert <[hidden email]>

> $ wc -l /home/raphael/.listNotAptable.ignore
> 19 /home/raphael/.listNotAptable.ignore

Running that script every now and then in a cronjob or after apt-get update
has resulted very helpful.

More info:
http://my.opera.com/atomo64/blog/2008/03/09/where-to-put-such-a-script

>
> Marc
>
> Footnotes:
> [1]  Such as kernel packages, binary kernel modules built from sources
>      available in the archive, local configuration packages, ...

Cheers,
Raphael



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

Franklin PIAT
In reply to this post by debian (Bugzilla)
Hello,

On Thu, 2008-05-29 at 14:40 +0200, Kai Wasserbäch wrote:

> Marc 'HE' Brockschmidt schrieb:
> > For some time now, I have been thinking about the problem of packages
> > which are removed from the archive at some point, without an (enforced)
> > transition to a new package name. Users of such packages keep them
> > around, usually never noticing the fact that no security (or other)
> > support is available anymore.
>
> I have somewhat of a deja-vù here with that thread.
> [..] So the solution then was "the user must check aptitudes obsolete
> category".

We might assume that Debian is only used in managed environment, where
system admins actually RTFM.

But if we aim world domination (i.e. reach true end-users), we can't
expect system-owners to actually read the fine manuals. (It's a fact,
right ?).

I wouldn't be comfortable telling my [brother|sister|friend], who's
system would have been compromised due to an obsolete packages, that
it's their fault because they should have checked "obsolete" package, as
explained in the fine manual...

Also, any pop-up/warning based solution will merely lead people to
ignore or disable them.


PROPOSAL : Remove obsolete packages on upgrade :

If we remove a package in a release, there is probably good reason for
that (!). So I tend to think that we should automatically remove the
package during systems upgrades (by default).

One could create dummy transition packages that `provides` the removed
package :

 - It could be named like "flashplugin-is-deprecated-in-lenny".
 - It's description should have appropriate comments (why was the
   package removed).
 - It should suggest replacements.
 - Such transition package would only be created for package that were
   actually in the previous release (i.e not for package that appeared
   and disappeared during a given `testing` cycle).
 - Those packages might have their own section.

Pros :
 - The user could still "Hold" the old package to prevent removal (which
   state properly describe the package status).
 - The user could still use another [unofficial] apt source, that
   actually provide the package, so the package isn't removed.
 - Users using lenny that search for a package removed since etch
   would actually find it (and know it is in "removed from archive") !
 - If a package moves from main to contrib or non-free, we could use the
   same transition, so one would know about it
   (package named like "foobar-is-now-in-non-free").
 - Using package-dependencies means that it would "just work" with any
   existing tool.

Cons :
 - "One" has to create, maintain (and remove) those packages !
 - It uses space in the mirrors.

I gave a try to automatically build such transition package. Currently
that about 460 package (we could merge some of them, like libapache* ).

The source's control would look like :
http://www.klabs.be/~fpiat/linux/debian/proposals/2008-05-30_package-removal/debian/control
Here's the script (very ugly currently).
http://www.klabs.be/~fpiat/linux/debian/proposals/2008-05-30_package-removal/refresh.sh

Any comment ?

Franklin


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Handling of removed packages

Russ Allbery-2
In reply to this post by Mike Bird-2
Mike Bird <[hidden email]> writes:

> Many people do extra levels of testing before
> rolling out updates with "dpkg -i".  With "apt-get"
> you never know when the package lists will be updated.

Uh... the package lists are updated when you run apt-get update.  I must
be missing something.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

12