[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#17922: pkg-order: the mother of all wishlists

	[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.

 "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: