Re: Bug#17922: pkg-order: the mother of all wishlists
Hi,
[also posting to debian-devel for more coverage. Please follow
up to debian-devel@lists.debian.org]
>>"Santiago" == Santiago Vila <sanvila@unex.es> writes:
I am going to keep this bug around as a reminder, at least for
a bit [until dftp gets released], but I am not likely to implement
any of it (soon, anyway). (I'm tempted to move the pkg-order script
into /usr/doc/examples ;-).
You see, pkg-order is a proof of concept script. It is more a
demonstration of various aspects of the underlying library; rather
than a decent implementation of a useful tool.
All that you propose is not hard, but pkg-order is a general
purpose library. What you are proposing is a particular tool that
should depend on this library. (And there already is a package that
does all this and more).
Santiago> How could pkg-order be used to upgrade from bo to hamm? In
Santiago> this case, we do not only want to install new packages but
Santiago> also remove a lot of them.
To upgrade from bo to hamm using the pkg-order library one
should use Roman's excellent dftp. It does everything that the report
asks for, and more. It uses the pkg-order library as a backend (which
is how I intended pkg-order to be used.
The pkg-order <Packages file of New packages> allows it to be
tested quickly, but is awfully cumbersome to use in practice; the
solution ftp uses is to build the internal list of packages to be
installed one package at a time (I think). The underlying library is
quite more flexible than than pkg order.
Santiago> Packages we don't want to have installed could be removed by
Santiago> hand, but how will we know which is the right order for
Santiago> *removing* them?
I don't know if dftp handles removes; there are issues there
that need careful handling, especially with the kind of multiple
package dependencies involved in upgrading from libc5 to libc6. But I
have to look at the issue in more detail before I can be sure I have
all the invariants right.
Santiago> I would like to propose some ideas:
Santiago> 1) Currently, my typical use of pkg-order is:
Santiago> pkg-order --installed-packages status new-Packages
Santiago> In this case it is assumed that we start from "status" and
Santiago> we want to go to "status + new-Packages". If package
Santiago> removing is ever implemented, I would propose to change the
Santiago> "user interface" to this:
Santiago> pkg-order --installed-packages status Packages2
Santiago> This means that "Packages2" (or "status2") is the complete
Santiago> set of packages we want to have at the end. pkg-order would
Santiago> then remove packages in status which are not in Packages2,
Santiago> and install packages in Packages2 which are not in status
Santiago> (in the right order).
The solution, of course, is to hack pkg-order and use the
builtin parser to read the Packages2 file into a list, loop over the
packages in the list, selecting the ones not installed, and create
the new list from them.
A second loop over the installed list, and selecting packages
not in the Packages2 file shall constitute the removed list.
Santiago> [ I must say that even if package removing is not
Santiago> implemented, this new syntax would make things easier,
Santiago> because when I have to generate a new-Packages file, I have
Santiago> to *exclude* by hand the packages I have already installed
Santiago> ].
Hmmm. It is easy enough to add a list-diff routine, which
takes two package lists and generates packages in A which are not in
B (It is about 4 lines of perl, and takes less than 5 minutes to
write, I just don't know where to place it in the class heirarchy).
I'll just code it into pkg-order example itself.
Then one can use the list-diff sub to create the new and
removed lists at will.
Santiago> 2) However this scheme is not enough yet. For upgrading from
Santiago> bo to hamm, we have sometimes to install some packages
Santiago> (oldlibs) just to be able to install another one, but we
Santiago> might want not to have any oldlibs installed at the end. The
Santiago> above proposed syntax would not be enough, then.
This is a known issue, but it is hard to get it right. The
depedencies can often be complex ...
Santiago> I would propose to a third argument to pkg-order's command
Santiago> line, with the following usage:
Santiago> pkg-order --installed-packages status All-Packages
Santiago> package-list
Santiago> where "status" are the packages which are already installed,
Santiago> package-list is a simple list of packages (one per line)
Santiago> that we want to have installed at the end, and All-Packages
Santiago> is a Package file that represents a "pool" of packages which
Santiago> are available to install (or not).
Santiago> Advantages of this new syntax:
Santiago> * The user would not have to create a reduced "Package" file
Santiago> from the list of packages he wants to install. Just
Santiago> uncompressing the Packages.gz file in the binary-i386
Santiago> directory (or concatenating some of them) would be enough.
As mentioned above, this is not hard to do in the new script.
Santiago> * The user would have just to manage files like
Santiago> "package-list", which are more easy to handle.
This is also simple to do: read all packages file. Read input
new packages file, and for each line, select package from all
packages list that are not in the installed list (probably need to
look at version number here too).
dftp does this all way better than this proposal ;-)
Santiago> I don't speak perl, so I have absolutely no idea how
Santiago> difficult could be to implement this.
This is not hard. But pkg-order is a general purpose
library. What you are proposing is a particular tool that should
depend on this library.
I'm gratified that my example script seems useful, but it is
not good as a tool; as you have discovered. I suggest you look at the
new experimental dftp when Roman releases it.
manoj
--
"We dare not tempt them with weakness. For only when our arms are
sufficient beyond doubt can we be certain beyond doubt that they will
never be employed." John F. Kennedy (from his Inaugural Address)
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: