1:42 p.m.
On Mon, Oct 17, 2005 at 06:01:13PM +0100, Paul Jakma wrote:
On Mon, 17 Oct 2005, Michal Jaegermann wrote:
>coming from different places you do not always control, and keeping
>these specs _correct_, i.e. no forgetfulness, mistakes, ignorance,
>etc, for all future revisions.
How so? You can generate all the required packages from one spec
file.
Things do change and not always only in a revision number. If you
are grabbing everything from a given directory then in '%files'
section you may have a line like
/some/dir/files/*
and you are ok. If you start explicitely splitting that then you
need to be more specific and with every release you need check all
of this and every mistake in that process means a new update and
complaints all over the place that yum failed again.
>The problem which started all this thread, i.e. "asynchronous
>updates" causing conflict complaints, in no way will be helped by a
>split you envision.
I'm not sure how you reach that conclusion.
That is simple. Assume that you have installed packages
package-bin-1.0.0-1.i386
package-bin-1.0.0-1.x86_64
package-common-1.0.0-1.noarch
Both "bin" packages depend on 'package-common-<right_version>'.
They have to. Now you try to update to package-bin-1.0.0-2.x86_64
without touching package-bin.i386. That immediately pulls in
package-common-1.0.0-2.noarch. Boom! Failed dependencies! This is
not even spurious as there are no guarantees that files in
package-common-1.0.0-1.noarch and package-common-1.0.0-2.noarch are
the same and if you will will go to package-common-1.1.0-1.noarch
then you _know_ that they are different because at least this is the
case for %doc directory. If you will try to force installing both
package-common-1.0.0-1.noarch and package-common-1.0.0-2.noarch then
you have collisions. Back to the square one.
What you gained above is that removing package-bin.i386 will not
mess up anything in package-common.noarch. So for a huge effort
you are a small bit ahead but not far enough.
Michal
2:51 p.m.
New subject: x86-64 rawhide update obnoxiousness
On Mon, 17 Oct 2005, Michal Jaegermann wrote:
Things do change and not always only in a revision number. If you
are grabbing everything from a given directory then in '%files'
section you may have a line like
/some/dir/files/*
and you are ok. If you start explicitely splitting that then you
need to be more specific and with every release you need check all
of this and every mistake in that process means a new update and
complaints all over the place that yum failed again.
Hmm, I don't see why that would be so really.
- rpmbuild will complain about unpackaged files (indeed, it's now an
error - no rpm at all).
- Files already listed are unlikely to change their type all of a
sudden.
- Even easier (if multi-arch in one package were possible) Rpmbuild
could potentially just automatically check the arch of files when
packaging and annotate the files accordingly (it already examines
files to work out dependencies)
- The common case for 'overlap' files is documentation, these
have been annotated with %doc in spec files for a long time (and
hence could automatically be hived off to a noarch package by
rpmbuild..)
- Really, from experience, this just isn't that difficult to
maintain. Enumerating build dependencies and unobvious dependencies
takes far more effort when maintaining spec files, particularly if
you want a spec file to work across multiple releases of a distro.
(But, I only maintain a spec file for one package, so maybe I
just don't add/remove files from this package often enough..)
That is simple. Assume that you have installed packages
package-bin-1.0.0-1.i386
package-bin-1.0.0-1.x86_64
package-common-1.0.0-1.noarch
Both "bin" packages depend on 'package-common-<right_version>'.
They have to. Now you try to update to package-bin-1.0.0-2.x86_64
without touching package-bin.i386. That immediately pulls in
package-common-1.0.0-2.noarch. Boom! Failed dependencies!
Of course, and this case is no different from the case of dependency
chains on single-arch only.
Different problem, solution is "use yum" - it works out the
dependencies.
What you gained above is that removing package-bin.i386 will not
mess up anything in package-common.noarch. So for a huge effort
you are a small bit ahead but not far enough.
It'd be a huge effort yes, but it *would* solve it.
The other alternative is multiple-arch packages, with arch-dependent
files annotated or sectioned in some way (as IRIX did it, and IRIX
had not 2 but 3 different ABIs ;) - worked well, but the packages are
obviously bigger).
Another possibility: Reference count the files. Last package
uninstalled removes the file. But that doesnt allow higher-level
package management systems to spot such dependencies though.
regards,
--
Paul Jakma paul(a)clubi.ie paul(a)jakma.org Key ID: 64A2FF6A
Fortune:
Where there are visible vapors, having their prevenance in ignited
carbonaceous materials, there is conflagration.
4:45 p.m.
New subject: x86-64 rawhide update obnoxiousness
On Mon, Oct 17, 2005 at 08:51:12PM +0100, Paul Jakma wrote:
Another possibility: Reference count the files. Last package
uninstalled removes the file.
That is exactly what to me looks like something sane in the whole
context. Similar to how 'unlink' works. Files are removed only
when the last reference is gone. It appears that something of that
sort already happens for directories but maybe I am misinterpreting
some observations.
Obviously you are still left with cases, like mentioned /bin/tcsh,
where you have really different files but with the same name and you
install both "owner" packages. That sounds like a bug although it
appears that one can have some "messy rules". Say, in x86_64/i386
situation x86_64 is "preferred" and a file from that architecture
cannot be replaced with another variant. So even if you had
tcsh.x86_64 and tcsh.i386 packages installed and you managed somehow
to remove the first one then you are left with x86_64 executables in
/bin/tcsh. Not that I like such contortions very much, and cleaning
that up would be much preferred, but with a quick peek on my
systems I did not notice cases where this would really apply.
Maybe you cannot do that anymore?
But that doesnt allow higher-level
package management systems to spot such dependencies though.
How that would be really different?
Michal
9:23 p.m.
New subject: x86-64 rawhide update obnoxiousness
On 10/17/2005 05:45:22 PM, Michal Jaegermann wrote:
On Mon, Oct 17, 2005 at 08:51:12PM +0100, Paul Jakma wrote:
>
> Another possibility: Reference count the files. Last package
> uninstalled removes the file.
That is exactly what to me looks like something sane in the whole
context. Similar to how 'unlink' works. Files are removed only
when the last reference is gone. It appears that something of that
sort already happens for directories but maybe I am misinterpreting
some observations.
Obviously you are still left with cases, like mentioned /bin/tcsh,
where you have really different files but with the same name and you
install both "owner" packages.
I think that allowing multiple owners and ref-counting is the right thing to
do. However, I also believe that librpm had better check that the files are
identical (judged by size and md5 sum) before it allows the overlapping
install. Nasty consequences are likely if this is not enforced.
With x86_64 multilib dual ownership allready occurs in rpmdb, for example:
# rpm -qf --queryformat "%{name}-%{version}-%{release}.%{arch}\n"
/usr/share/man/man3/zlib.3.gz
zlib-devel-1.2.2.2-5.fc4.x86_64
zlib-devel-1.2.2.2-5.fc4.i386
Not sure how that works today, though.
Regards, Willem Riede.
11:06 p.m.
New subject: x86-64 rawhide update obnoxiousness
On Tue, Oct 18, 2005 at 02:23:07AM +0000, Willem Riede wrote:
With x86_64 multilib dual ownership allready occurs in rpmdb, for example:
# rpm -qf --queryformat "%{name}-%{version}-%{release}.%{arch}\n"
/usr/share/man/man3/zlib.3.gz
zlib-devel-1.2.2.2-5.fc4.x86_64
zlib-devel-1.2.2.2-5.fc4.i386
Not sure how that works today, though.
One of the observed issues was that, in at least in some cases, you
may remove one of these packages and you will end up with "missing"
error for zlib.3.gz if you will try 'rpm -V zlib-devel'. That
particular one is not hard to fix but is a PITA on a system
maitenance and it should not really happen.
Other nastie is when you were trying an update and, for whatever
reasons, this succeeded only with one package and you ended up with
two different versions. The current managment tools will fail to
notice that this update was not complete and something needs yet to
be done.
Michal
10:15 p.m.
New subject: x86-64 rawhide update obnoxiousness
On Mon, 17 Oct 2005, Michal Jaegermann wrote:
That is exactly what to me looks like something sane in the whole
context. Similar to how 'unlink' works. Files are removed only
when the last reference is gone. It appears that something of that
sort already happens for directories but maybe I am misinterpreting
some observations.
It'd solve the "remove" problem.
Obviously you are still left with cases, like mentioned /bin/tcsh,
where you have really different files but with the same name and
you install both "owner" packages. That sounds like a bug although
it appears that one can have some "messy rules". Say, in
x86_64/i386 situation x86_64 is "preferred" and a file from that
architecture cannot be replaced with another variant. So even if
you had tcsh.x86_64 and tcsh.i386 packages installed and you
managed somehow to remove the first one then you are left with
x86_64 executables in /bin/tcsh.
Well it's two seperate bugs really:
1. It appears rpmlib's "swallowing" process does not check the files
are actually same, as you had initially thought. In lieu of a
better solution than "swallowing" multi-arch file conflicts, it
should check the MD5/SHA1 of the file being considered for
installation against the file on disk - as you had thought it did
initially.
2. A packaging / fs layout bug: We really should put x86-64 binaries
in a seperate directory, bin64, or bin/64. This is how both
Solaris 10 and IRIX do things and it allows multi-arches to be
installed without clobbering the binaries. (You can play tricks
with bind mounts to make bin/$ISA appear as bin..).
/usr/libexec has the same "undefined arch, hence target
installation directory for multiple arches" problem.
> But that doesnt allow higher-level package management systems to
> spot such dependencies though.
How that would be really different?
Because the refcount would be a dependency, but that dependency isn't
expressed anywhere, hence it's invisible to yum. The problem is
similar to the dependency chain you noted in a previous mail, except
your package management system can't see it and can't do anything
about it.
X.i386 -> Y.i386 (X depends on Y)
A.x86-64 -> Y.x86-64
X.x86-64 is to be upgraded, and depends on a newer version of
Y.x86-64, which is pulled in and upgraded.
However, there is no dependency information to tell you that files of
Y.x86-64 are shared with Y.i386 (unless you do something like 'rpm
-qf' for each file to be removed, but that's cumbersome), so you
could end up with documentation from a newer Y.x86-64 which is
confusing if you want to use binaries from Y.i386.
Of course, you could just simply make a rule that packages of the
same name *must* always be upgraded in lock-step. (And that really
should then be enforced by rpmlib).
Michal
regards,
--
Paul Jakma paul(a)clubi.ie paul(a)jakma.org Key ID: 64A2FF6A
Fortune:
Why aren't fishmongers generous? Their business makes them selfish.
6826
days inactive
6827
days old
5 comments
3 participants
participants (3)
-
Michal Jaegermann -
Paul Jakma -
Willem Riede