Re: apt-get update, a wishlist feature as tag in cvs
On Thu, Feb 10, 2000 at 04:26:26PM +0100, Fabrice Gautier wrote:
> > run dselect and mark as "Hold" (press H) any packages which you
> > don't want to be automatically upgraded.
>
> As a user, i think this is paintfull.
well, what do you expect - you run "apt-get dist-upgrade" and you are
telling the system to upgrade everything in the distribution.
the "trouble" is that you also want some exceptions...some packages that
don't get upgraded. HOW do you expect the system to know which packages
not to upgrade if you don't tell it?
apt-get can't read your mind so at some point, you are going to have to
tell it what not to upgrade. there really isn't any way around that.
> For example if i wanted to upgrade all my packages only when the
> upstream version number change and not when only the debian version
> number change i would have to go throught every packages and check
> version numbers then "unhold" all the packages that have a new
> upstream version number,then install the whole, then "hold" them bask
> i want to ugrade.
ok, an "--only-upgrade-if-major-revision" option would be useful.
even this is more complicated than it would initially seem - e.g.
what do you do if package A has a major upgrade, and it depends on a
new version of package B (which has only had a minor debian revision
update). the obvious answer is that you upgrade both or neither. the
important point here is that you've got to have code to detect and
cope with this situation. it gets even more complicated when package A
depends on package B which depends on package C.
i'm sure there are many other similar "gotchas" - this is just the first
one that occurred to me.
i don't mean to say that this feature is a bad idea. in fact, i think
it's a useful and good idea. i just doubt that implementation is going
to happen overnight.
perhaps a "--dont-upgrade-if-larger-than 500k" option would also be
useful (but i can see that could also cause problems if, say, cpp gets
upgraded but gcc doesn't because it's over the size limit)
> > Held packages will NOT be automatically upgraded by 'apt-get
> > dselect-upgrade' or 'apt-get dist-upgrade'. they can, however, still be
> > upgraded manually.
>
> Manually is, i think, the problem.
generally when you want exceptions to some automated system, you have to
do them manually. this is neither good nor bad, it just is.
you can respond to this in one of several ways - you can bemoan the fact
that debian's AI doesn't cut the mustard because we haven't implemented
the psychic DWIM subroutines to read your mind.
or you can appreciate the flexibility that a manual override gives you -
at least you have the capability to override when you need to.
a third option is to write the code to add the functionality you need.
> > remember to mark it Hold again after upgrading. e.g
>
> User may not remember well if they do this for a bunch of packages
the tools are available. it's not debian's fault if a user doesn't
bother to use them.
> The great thing would be a script that:
>
> 1°) list all packages that qualify a criteria (where the criteria
> could be a chnge between the old and new version: new upstream version
> number, new 'tag', new epoch, new dependency or anything )
> 2°) mark all of them as install
> 3°) run apt-get dist-upgrade or whatever install those packages
> 4°) restore the prvious state for our list of packages
ok, you've got yourself the beginnings of a specification - start
coding. i'm sure we'd all love to see the results.
> The coolest thing would be to be abble to access the changelog to
> check for bug closing.
i recall reading recently here on debian-devel that someone is working
on making the changelogs accessible from a web browser. when that
happens, it shouldn't be too hard to use lynx or snarf or something to
grab it automatically for a command-line tool.
> And one one would say in his conffile 'upgrade packages when bug
> #98765 is closed' etc...
i don't think this really needs a conffile. a special-purpose tool (or
set of tools) would do the job without the complication of a generic
"upgrade rules" config file. after all, this is something to handle a
special case, an exception, not a routine operation.
rough sequence of events to be performed:
1. download bug report #98765
2. parse it to find out which package it refers to.
3. download changelog for package
4. parse it to find out if it closes #98765. there are several valid
ways that this can be specified in a changelog.
5. if it does, then "apt-get install PACKAGE"
steps 1 & 2 can be skipped if the user specifies both the package name
and the bug number.
(btw, sometimes bugs get fixed but the bug report never gets closed or
listed in the changelog)
i think the bottom line is that most of the features you want would
probably be of some use to some people - even many people. however, the
question is: is the amount of time it takes to write & debug the feature
worth the effort?
if the feature is important to you, but not to anyone else working on
apt or dpkg then you can't really expect them to drop their priorities
just to work on your needs. you're the one with the enthusiasm for
the feature, you write it - or pay someone to write it, or convince
someone else that it's a great idea that really needs to be implemented
now....doing any of these will require more work on your part than just
complaining "it doesn't have obscure feature X".
Regards,
craig
ps: not intended as a flame, just a reality check.
--
craig sanders
Reply to: