Re: Package splitting and upgrades
On Fri, Mar 01, 2002 at 11:41:58AM +0100, Wichert Akkerman wrote:
> Previously Santiago Vila wrote:
> > When a package `foo' in potato is split in two for woody, `foo' and `bar',
> > it is considered acceptable that people upgrading from potato to woody
> > lose the functionality provided by `bar' and have to read the release
> > notes to know why?
>
> People should just use a proper UI like dselect or probably aptitude
> as well so they can handle Recommends and get proper upgrades.
So what you're suggesting is that the new package 'foo' should recommend
the package 'bar' so that "proper" frontends will automatically install
bar if you upgrade foo? IMO this is an ugly clutch. Why should foo
recommand bar just because bar used to be part of foo? Who says that bar
contains anything that justifies "a strong, but not absolute dependency"?
> Just using apt-get blindly is a guaranteed way to suddenly loose things
> (and if that is not documented it should be).
But what if I prefer the simple, elegant apt-get to the ugly and
convoluted dselect (or one of its alternatives)? Why should I be forced
to use a full-screen editor for something that I can (nearly) do with a
simple command line? Shouldn't it be a goal that even apt-get upgrade
will not lose anything on your system? I can live with installations
that are not quite complete (because of a missing recommends, for
example), but on upgrades this shouldn't happen. What about automatic
(e.g. nightly) upgrades? How can I use dselect for that easily?
> > Do we need a new dpkg field for this, maybe "Previously-in:", which is
> > understood by dselect and apt only on upgrades?
>
> No, we have a perfectly valid system already, people just don't use
> it properly.
I don't see, why Recommends or deselect is proper for that occassion.
- Sebastian
Reply to: