Donnie Berkholz pisze:
On 06:24 Wed 16 Apr , Ciaran McCreesh wrote:
What all are blocks used for?
a) Marking that two unrelated packages are mutually incompatible at
runtime because they happen to collide, for example on a commonly named
executable.
b) Marking that two related implementations are mutually incompatible at
runtime because they both provide the same binary.
c) Marking that a file that used to be provided by one package is now
provided by another package that is either depending upon or depended
upon by the original package.
d) Marking that a package has been moved into another package.
Are there any other uses?
A slight tweak that you may have already considered: a single package is
split into multiple packages with a metabuild (named the same as the
original single package) in a newer version -- for example, modularized
X.
For future EAPIs, being able to tell the package manager that your
block is of one of the types above will help the package manager smooth
out the upgrade path for users. For example, for class d) blocks such
as the recent coreutils / mktemp mess, the package manager can suggest
to the user to install the new package and then uninstall the old
package, rather than forcing the user to uninstall the old package by
hand (possibly leaving their system without critical utilities) and then
install the new package.
I strongly suspect that in many (but not all) cases the package manager
could be making users' lives a lot easier than it currently is...
Sounds like a great idea.
Thanks,
Donnie
Yes... and then all trashes like old libs are inside system. Other thing
is when some files gets from one package to other. If You install old
version of package "A" and then some of files get to package "A1" as an
update and some part of package "A" get's into "B" package. When we
update package "A" to "A1" we can be in trouble when installing
automaticly B and uninstalling "A". Think about that.
--
[email protected] mailing list
