9:17 p.m.
Here are some notes I typed up this weekend on a plane and in a truly
dull airport about yum changes in the upcoming test release.
Here they are:
Making yum repositories now:
Yum repositories are no longer created by yum-arch. There is a new
program, createrepo (http://linux.duke.edu/metadata/generate), that
creates the metadata. The metadata for rpm packages is the information
that describes the data stored in the payload of the rpm. createrepo
takes the metadata from each rpm in the repository and stores it in an
xml format that is simple and expedient to load the data from. This
makes it easier and more efficient for yum to resolve dependencies
and find out other important information about the packages a user
would want to install.
To create your own repository install the createrepo rpm and run:
create-repo /path/to/the/packages
It will recursively go through the directory you specify, find all
the rpm packages, and retrieve the pertinent metadata. Once this
command completes you should have a directory named 'repodata'
created in the directory path you specified on the command line.
The repodata directory will contain at least 4 files. They are:
repomd.xml - stores the information about the other metadata
files. It is a meta-metadata file. :) It has checksums and
timestamps for each file of the metadata.
primary.xml[.gz] - stores the critical information for listing and
dependency solving packages. It is the core of information for the
repository and it is normally the smallest of the files containing
package metadata.
filelists.xml[.gz] - stores the complete file listing for each
package. It also contains some information describing the files.
It distinguishes between files, directories and ghosted files in
the package.
other.xml[.gz] - stores any other information that is available from
the package. This file is available for completeness and convenience.
In particular, this file stores all the changelog information for
each package.
If you specified the -g option to createrepo and listed a groups file
(a comps.xml format file) then this file will also be copied to
the repodata directory.
Yum Changes:
1. Yum will no longer work with repositories generated with yum-arch.
The new format and the old format do not conlict with each other so
if you want to run createrepo and yum-arch on a single repository
that will work just fine. However, the new yum will not support
old-style repositories and there are no plans at this time to make
it possible.
2. When specifying packages on the command line and in the exclude
lists you can use complete version and arch strings now. In addition
to specifying:
yum install mypackage
you can now also specify:
yum install mypackage-1.1
The following version/arch string formats are accepted:
name
name-ver
name-ver-rel
name.arch
name-ver-rel.arch
epoch:name-ver-rel.arch
3. The config file has been enhanced in a number of ways. Inside the
config file you can now specify include=url://some/location/file at
any point. This allows you to include one config file inside another.
The file is included literally, as though typed in place. The include
option takes any url that yum is capable of handling (http, https,
ftp and file).
4. In addition to the above config change, yum also offers an
optional /etc/yum.repos.d directory for configurations. Each file
named with a .repo extension will be parsed and added to the set of
repositories listed in the yum.conf file. The format of these files
is identical to the listing of a repository in the yum.conf file:
[repository-id]
name=repository name
baseurl=url://path/to/repository
...
5. New command line options:
--obsoletes - tell yum to include obsoletes in its update processing
--enablerepo=repository-id - tell yum to enable the repository of
that id this option can be specified
multiple times on the command line.
This will override the 'enabled' option
to a repository in the configuration
file.
--disablerepo=repository-id - The logical opposite of the above.
Other new features will be added and they'll be described in more
detail then. This should give users an overview of the major changed
items in yum, so far.
hope this helps people.
-sv
1:24 a.m.
Hi,
I just tried the new yum (from rawhide) and it works great! Much much
better then the old stuff, does this mean I can nuke all headers from
the yum cache now?
Are any livna developers on this list? livna needs to be updated to the
new format :), so does macromedia.mplug probably.
Regards,
Hans
10:32 a.m.
On Mon, 2004-09-06 at 08:48 -0400, Konstantin Ryabitsev wrote:
On Mon, 2004-09-06 at 17:07 +0900, Naoki wrote:
> I missed the thread, what happened to 'upgrade' ?
yum --obsoletes update
I honestly fail to understand why this isn't the default.
Yum has improved _definitely_a_lot_, it works much better on mirrors
(and in the past it used to fail horribly and constantly due to mirror
misbehaviour).
But IMHO it places a lot of decisions on the enduser, failing in a scary
way when bad things happen.
Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
12:14 p.m.
On Mon, 2004-09-06 at 16:32 +0100, Rui Miguel Seabra wrote:
On Mon, 2004-09-06 at 08:48 -0400, Konstantin Ryabitsev wrote:
> On Mon, 2004-09-06 at 17:07 +0900, Naoki wrote:
> > I missed the thread, what happened to 'upgrade' ?
>
> yum --obsoletes update
I honestly fail to understand why this isn't the default.
Yum has improved _definitely_a_lot_, it works much better on mirrors
(and in the past it used to fail horribly and constantly due to mirror
misbehaviour).
But IMHO it places a lot of decisions on the enduser, failing in a scary
way when bad things happen.
osboletes can be what you set if you want.
just set obsoletes=1 in the [main] section of your yum.conf
however obsoletes should not be the default b/c of circular obsoletes.
ie:
foo obsoletes bar
baz osboletes foo
bar obsoletes baz
and if you don't think that happens, look around, it definitely does.
-sv
2:04 p.m.
On Mon, 2004-09-06 at 13:14 -0400, seth vidal wrote:
On Mon, 2004-09-06 at 16:32 +0100, Rui Miguel Seabra wrote:
> On Mon, 2004-09-06 at 08:48 -0400, Konstantin Ryabitsev wrote:
> > On Mon, 2004-09-06 at 17:07 +0900, Naoki wrote:
> > > I missed the thread, what happened to 'upgrade' ?
> >
> > yum --obsoletes update
>
> I honestly fail to understand why this isn't the default.
osboletes can be what you set if you want.
just set obsoletes=1 in the [main] section of your yum.conf
Oh, I've already done that. I just think it should be the default.
however obsoletes should not be the default b/c of circular
obsoletes.
ie:
foo obsoletes bar
baz osboletes foo
bar obsoletes baz
and if you don't think that happens, look around, it definitely does.
Well, I thought there was a process for package submission, review and
what not. Of course accidents happen. But this is no excuse, or is a
"meta packager" like yum not better than plain rpm in itself?
As far as I can see, I have to solve about as many problems as I did
without a metapackager (--obsoletes, --exclude=..., etc...). The job of
a meta packager is making things easier.
My praise was precisely that yum has had a giant step towards this goal,
but there are definitely corners to round.
Anyway, loops are not that hard to find, just mark where you've been
previously (prolog 101) and handle apropriately (ie, until repo fixes
it, I can't do anything that touches foo, bar or baz, may I proceed with
the rest?).
Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
2:38 p.m.
man, 06.09.2004 kl. 21.04 skrev Rui Miguel Seabra:
On Mon, 2004-09-06 at 13:14 -0400, seth vidal wrote:
> On Mon, 2004-09-06 at 16:32 +0100, Rui Miguel Seabra wrote:
> > On Mon, 2004-09-06 at 08:48 -0400, Konstantin Ryabitsev wrote:
> > > On Mon, 2004-09-06 at 17:07 +0900, Naoki wrote:
> > > > I missed the thread, what happened to 'upgrade' ?
> > >
> > > yum --obsoletes update
> >
> > I honestly fail to understand why this isn't the default.
>
> osboletes can be what you set if you want.
>
> just set obsoletes=1 in the [main] section of your yum.conf
Oh, I've already done that. I just think it should be the default.
> however obsoletes should not be the default b/c of circular obsoletes.
> ie:
> foo obsoletes bar
> baz osboletes foo
> bar obsoletes baz
>
> and if you don't think that happens, look around, it definitely does.
Well, I thought there was a process for package submission, review and
what not. Of course accidents happen. But this is no excuse, or is a
"meta packager" like yum not better than plain rpm in itself?
As far as I can see, I have to solve about as many problems as I did
without a metapackager (--obsoletes, --exclude=..., etc...). The job of
a meta packager is making things easier.
My praise was precisely that yum has had a giant step towards this goal,
but there are definitely corners to round.
Anyway, loops are not that hard to find, just mark where you've been
previously (prolog 101) and handle apropriately (ie, until repo fixes
it, I can't do anything that touches foo, bar or baz, may I proceed with
the rest?).
Yup, ran into that when running "daily yum update" on a network, and
discovered that "xmms-mp3" (installed from apt) blocked "xmms", and
when
xmms couldn't be upgraded, there is no reason to even try with the rest,
right?
Rui
But this looks cool!
Is there any plans for integrating rpm with yum - so that rpm would ask
"you need dependancy foo, bar, baz.so in order to install this package,
shall i ask yum to fetch them for you? (y/n)"
BTW. Guess i forgot to introduce my self:
My name is Kyrre Ness Sjøbæk, and i come from Norway, where i go to
"high-school" (think that is the closest matching term - probably
university next year) and also helps rolling out/maintaining Linux on my
school, while feeling pity for the windows-guy who dont have any good
scripting tools at hand...
I know some programming (a bit of that and another bit of that), but
that is probably not what i'm best at.
I think i mostly joined this list in order to "see whats going on", but
if there is anything i might help out with, ill be glad.
Kyrre Ness Sjøbæk
4:23 p.m.
On Mon, 2004-09-06 at 21:38 +0200, Kyrre Ness Sjobak wrote:
Is there any plans for integrating rpm with yum - so that rpm would
ask
"you need dependancy foo, bar, baz.so in order to install this package,
shall i ask yum to fetch them for you? (y/n)"
I wouldn't expect it to ever happen, since rpm is the base where yum
works on :)
BTW. Guess i forgot to introduce my self:
Welcome :)
Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
4:26 p.m.
On Mon, 2004-09-06 at 21:38 +0200, Kyrre Ness Sjobak wrote:
Is there any plans for integrating rpm with yum - so that rpm would
ask
"you need dependancy foo, bar, baz.so in order to install this package,
shall i ask yum to fetch them for you? (y/n)"
Instead of integrating yum into rpm, just use a tool (such as yum
itself) to install your packages instead of rpm. I don't know offhand
if yum already supports this, but if not, it should. ;-)
The graphical tools like system-install-packages and friends should also
then integrate with yum.
I'm sure the maintainers will accept patches for such a feature. ;-)
7 p.m.
On Mon, 2004-09-06 at 17:26 -0400, Sean Middleditch wrote:
On Mon, 2004-09-06 at 21:38 +0200, Kyrre Ness Sjobak wrote:
> Is there any plans for integrating rpm with yum - so that rpm would ask
> "you need dependancy foo, bar, baz.so in order to install this package,
> shall i ask yum to fetch them for you? (y/n)"
Instead of integrating yum into rpm, just use a tool (such as yum
itself) to install your packages instead of rpm. I don't know offhand
if yum already supports this, but if not, it should. ;-)
The graphical tools like system-install-packages and friends should also
then integrate with yum.
I'm sure the maintainers will accept patches for such a feature. ;-)
The question becomes how to do this sensibly.
yum install /some/path/to/an/rpm
that's possible
except I get an equal number of requests for:
yum install /some/file/that/some/package/in/a/repository/provides.
it's not impossible to check for but it means searching harder.
the biggest limitation is time.
I'm one guy.
-sv
12:24 a.m.
On Tue, 2004-09-07 at 03:00, seth vidal wrote:
On Mon, 2004-09-06 at 17:26 -0400, Sean Middleditch wrote:
> On Mon, 2004-09-06 at 21:38 +0200, Kyrre Ness Sjobak wrote:
>
> > Is there any plans for integrating rpm with yum - so that rpm would ask
> > "you need dependancy foo, bar, baz.so in order to install this package,
> > shall i ask yum to fetch them for you? (y/n)"
>
> Instead of integrating yum into rpm, just use a tool (such as yum
> itself) to install your packages instead of rpm. I don't know offhand
> if yum already supports this, but if not, it should. ;-)
>
> The graphical tools like system-install-packages and friends should also
> then integrate with yum.
>
> I'm sure the maintainers will accept patches for such a feature. ;-)
The question becomes how to do this sensibly.
yum install /some/path/to/an/rpm
that's possible
except I get an equal number of requests for:
yum install /some/file/that/some/package/in/a/repository/provides.
it's not impossible to check for but it means searching harder.
Might be harder to search for but that IS an awfully nice and useful
feature.
- Panu -
1:06 p.m.
tir, 07.09.2004 kl. 07.24 skrev Panu Matilainen:
On Tue, 2004-09-07 at 03:00, seth vidal wrote:
> On Mon, 2004-09-06 at 17:26 -0400, Sean Middleditch wrote:
> > On Mon, 2004-09-06 at 21:38 +0200, Kyrre Ness Sjobak wrote:
> >
> > > Is there any plans for integrating rpm with yum - so that rpm would ask
> > > "you need dependancy foo, bar, baz.so in order to install this
package,
> > > shall i ask yum to fetch them for you? (y/n)"
> >
> > Instead of integrating yum into rpm, just use a tool (such as yum
> > itself) to install your packages instead of rpm. I don't know offhand
> > if yum already supports this, but if not, it should. ;-)
> >
> > The graphical tools like system-install-packages and friends should also
> > then integrate with yum.
> >
> > I'm sure the maintainers will accept patches for such a feature. ;-)
>
> The question becomes how to do this sensibly.
>
> yum install /some/path/to/an/rpm
>
> that's possible
>
> except I get an equal number of requests for:
>
> yum install /some/file/that/some/package/in/a/repository/provides.
>
> it's not impossible to check for but it means searching harder.
Might be harder to search for but that IS an awfully nice and useful
feature.
- Panu -
Yes, that is one way to solve it.
What i was more thinking about, was really "integrating" (sorry if i use
the wrong wording) yum into rpm. Yum has an API, yes?
Only that will create a circular dependence rpm/yum - make it a compile
option?
But something that WILL be needed if this actually gets implemented, is
some "--noyumdepsolve" and "--silent-answer-yes" flags - rpm is very
useful also in scripts. (is there some way to detect if a program is
getting called by a script (non-interactive) or by an actual person on a
terminal? If so, --silent-answer-yes should be default imo. That option
could be _very_ useful when talking about rpm that require a license to
be read etc. (ever tried installing the Macromedia Flash rpm's through a
script? /me likes Dag Wieers, who makes good non-interactive
flash-rpms...)
Ofcourse it is possible to tell people to use yum instead of rpm - but
how nice is that? "Hey all you people, forget about rpm - always use yum
instead!!" - or not? "rpm -ivh two-lettersTAB" is something that is
built into my fingers... But a new tool could work (something like
"rpm-depsolve -ivh my-package.fc2.rpm"
Only problem now is actually finding a good programmer, and a good way
to do this.
2:19 p.m.
On Tue, 2004-09-07 at 20:06 +0200, Kyrre Ness Sjobak wrote:
Yes, that is one way to solve it.
What i was more thinking about, was really "integrating" (sorry if i use
the wrong wording) yum into rpm. Yum has an API, yes?
Again, why? You don't get anything for this. Just use yum all the time
and never invoke rpm. This is similar to how most users in Debian
systems use apt-get all the time, but almost never directly invoke dpkg.
And dpkg has no apt integration at all.
The tools you use should be built on yum. What you're asking for is to
allow tools to be built on rpm but have yum's features. That's a bad
way to design the system, for many reasons, not the least of which is
because the package manager should be able to just do its job; adding
more meta-packager features to RPM is just going to increase the chance
of bugs (and bugs which can and will affect the core of the package
manager)
Only that will create a circular dependence rpm/yum - make it a compile
option?
But something that WILL be needed if this actually gets implemented, is
some "--noyumdepsolve" and "--silent-answer-yes" flags - rpm is very
useful also in scripts. (is there some way to detect if a program is
getting called by a script (non-interactive) or by an actual person on a
terminal? If so, --silent-answer-yes should be default imo. That option
You can check if stdin is a (pseudo-)terminal or a pipe; the former
indicates a user, the latter a script. Any time the user is directly
interacting with the app, they should be using a PTY/TTY. Scripts may
still use a PTY however; it's good to always be able to explicitly tell
the tool that you're a script.
could be _very_ useful when talking about rpm that require a license
to
be read etc. (ever tried installing the Macromedia Flash rpm's through a
script? /me likes Dag Wieers, who makes good non-interactive
flash-rpms...)
The problem there is that, put bluntly, RPM sucks for applications. It
is a low-level packaging tool intended for bundling the components of a
distribution. It never was intended for third-party applications, and
to this day still has huge problems supporting them, as the situation
with Macromedia demonstrates.
For license agreements, RPM would need meta-information to carry the
full license text and allow a package to note that agreement is
required; this would be done before any of the package installations
even start. Currently, you'd have to put this in a script (and pray you
made it portable enough *and* not use any binaries in your package,
since it isn't unpacked yet, and make it pretty, and make it
consistent... it's just not feasible) which would a) be executed
sometime during installation, and b) have to report an error to rpm if
the user declines, which would most likely cause all sorts of
"Installation Failed!!! Here's some geeky nonsensical techie debug spew
you, the user, don't understand or care about, because you are aware of
the fact that you said 'No': <rpm error report>" dialogs or console
messages to appear.
There are still then problems stemming from the fact that every version
of every distribution is incompatible due to either developers not
versioning their ABIs right, or packagers taking perfectly well
versioned libraries and tools and putting them into poorly versioned and
inconsistent packages (like the broken curl RPM in Fedora), but that's a
whole different topic. ~_^
Ofcourse it is possible to tell people to use yum instead of rpm - but
how nice is that? "Hey all you people, forget about rpm - always use yum
instead!!" - or not? "rpm -ivh two-lettersTAB" is something that is
built into my fingers... But a new tool could work (something like
"rpm-depsolve -ivh my-package.fc2.rpm"
If you're alright with requesting a tool like 'rpm-depsolve', I don't
see at all how you can argue against just using yum. ;-)
Only problem now is actually finding a good programmer, and a good way
to do this.
--
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.
2:51 p.m.
tir, 07.09.2004 kl. 21.19 skrev Sean Middleditch:
On Tue, 2004-09-07 at 20:06 +0200, Kyrre Ness Sjobak wrote:
> Yes, that is one way to solve it.
>
> What i was more thinking about, was really "integrating" (sorry if i use
> the wrong wording) yum into rpm. Yum has an API, yes?
Again, why? You don't get anything for this. Just use yum all the time
and never invoke rpm. This is similar to how most users in Debian
systems use apt-get all the time, but almost never directly invoke dpkg.
And dpkg has no apt integration at all.
The tools you use should be built on yum. What you're asking for is to
allow tools to be built on rpm but have yum's features. That's a bad
way to design the system, for many reasons, not the least of which is
because the package manager should be able to just do its job; adding
more meta-packager features to RPM is just going to increase the chance
of bugs (and bugs which can and will affect the core of the package
manager)
>
> Only that will create a circular dependence rpm/yum - make it a compile
> option?
>
> But something that WILL be needed if this actually gets implemented, is
> some "--noyumdepsolve" and "--silent-answer-yes" flags - rpm is
very
> useful also in scripts. (is there some way to detect if a program is
> getting called by a script (non-interactive) or by an actual person on a
> terminal? If so, --silent-answer-yes should be default imo. That option
You can check if stdin is a (pseudo-)terminal or a pipe; the former
indicates a user, the latter a script. Any time the user is directly
interacting with the app, they should be using a PTY/TTY. Scripts may
still use a PTY however; it's good to always be able to explicitly tell
the tool that you're a script.
> could be _very_ useful when talking about rpm that require a license to
> be read etc. (ever tried installing the Macromedia Flash rpm's through a
> script? /me likes Dag Wieers, who makes good non-interactive
> flash-rpms...)
The problem there is that, put bluntly, RPM sucks for applications. It
is a low-level packaging tool intended for bundling the components of a
distribution. It never was intended for third-party applications, and
to this day still has huge problems supporting them, as the situation
with Macromedia demonstrates.
For license agreements, RPM would need meta-information to carry the
full license text and allow a package to note that agreement is
required; this would be done before any of the package installations
even start. Currently, you'd have to put this in a script (and pray you
made it portable enough *and* not use any binaries in your package,
since it isn't unpacked yet, and make it pretty, and make it
consistent... it's just not feasible) which would a) be executed
sometime during installation, and b) have to report an error to rpm if
the user declines, which would most likely cause all sorts of
"Installation Failed!!! Here's some geeky nonsensical techie debug spew
you, the user, don't understand or care about, because you are aware of
the fact that you said 'No': <rpm error report>" dialogs or console
messages to appear.
There are still then problems stemming from the fact that every version
of every distribution is incompatible due to either developers not
versioning their ABIs right, or packagers taking perfectly well
versioned libraries and tools and putting them into poorly versioned and
inconsistent packages (like the broken curl RPM in Fedora), but that's a
whole different topic. ~_^
>
> Ofcourse it is possible to tell people to use yum instead of rpm - but
> how nice is that? "Hey all you people, forget about rpm - always use yum
> instead!!" - or not? "rpm -ivh two-lettersTAB" is something that is
> built into my fingers... But a new tool could work (something like
> "rpm-depsolve -ivh my-package.fc2.rpm"
If you're alright with requesting a tool like 'rpm-depsolve', I don't
see at all how you can argue against just using yum. ;-)
Hmm... somhow using yum to install a local package feels wrong... Hmm...
think ill acctually have to write some prototype stuff, then.
rpm-depsolve, here i come! :P
Always wanted to create some "core" utility...
>
> Only problem now is actually finding a good programmer, and a good way
> to do this.
>
>
--
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.
3:58 p.m.
On Tue, 2004-09-07 at 21:51 +0200, Kyrre Ness Sjobak wrote:
tir, 07.09.2004 kl. 21.19 skrev Sean Middleditch:
> If you're alright with requesting a tool like
'rpm-depsolve', I don't
> see at all how you can argue against just using yum. ;-)
>
Hmm... somhow using yum to install a local package feels wrong... Hmm...
think ill acctually have to write some prototype stuff, then.
"Feels" wrong? How? It makes perfect sense. Nothing wrong with a
separate tool either, although in the end all it would do is just invoke
yum, so it (to me) makes sense to just have yum do the work.
Yum itself has to handle the installation anyhow to make sure it
actually works. Imagine a case where you are installing a local package
foo, which provides a virtual bar, and depends on baz, which requires a
package providing bar? Yum has to know about the package being manually
installed to be able to satisfy the dependencies properly. An
external/separate tool would pretty much be forced to take the local
package, calculate its dependencies, request them from Yum, and once
those are already installed, install the package requested by the user -
the sort of chain above could not ever be properly resolved in this
case.
Again, there isn't anything wrong with yum installing local packages.
It's the natural tool to do the job, and there isn't any compelling
reason to do otherwise. "Feels wrong" does not count as a compelling
reason, either. ;-)
--
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.
4:10 p.m.
tir, 07.09.2004 kl. 22.58 skrev Sean Middleditch:
On Tue, 2004-09-07 at 21:51 +0200, Kyrre Ness Sjobak wrote:
> tir, 07.09.2004 kl. 21.19 skrev Sean Middleditch:
> > If you're alright with requesting a tool like 'rpm-depsolve', I
don't
> > see at all how you can argue against just using yum. ;-)
> >
>
> Hmm... somhow using yum to install a local package feels wrong... Hmm...
> think ill acctually have to write some prototype stuff, then.
"Feels" wrong? How? It makes perfect sense. Nothing wrong with a
separate tool either, although in the end all it would do is just invoke
yum, so it (to me) makes sense to just have yum do the work.
Yum itself has to handle the installation anyhow to make sure it
actually works. Imagine a case where you are installing a local package
foo, which provides a virtual bar, and depends on baz, which requires a
package providing bar? Yum has to know about the package being manually
installed to be able to satisfy the dependencies properly. An
external/separate tool would pretty much be forced to take the local
package, calculate its dependencies, request them from Yum, and once
those are already installed, install the package requested by the user -
the sort of chain above could not ever be properly resolved in this
case.
Again, there isn't anything wrong with yum installing local packages.
It's the natural tool to do the job, and there isn't any compelling
reason to do otherwise. "Feels wrong" does not count as a compelling
reason, either. ;-)
Okay. But since i do not know enough to fool around with the internals
of yum, ill write it (a prototype) as an external tool. And maybe somone
more knowledgable of yum might just like the idea and implement it?
--
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.
4:30 p.m.
Yum itself has to handle the installation anyhow to make sure it
actually works. Imagine a case where you are installing a local package
foo, which provides a virtual bar, and depends on baz, which requires a
package providing bar? Yum has to know about the package being manually
installed to be able to satisfy the dependencies properly. An
external/separate tool would pretty much be forced to take the local
package, calculate its dependencies, request them from Yum, and once
those are already installed, install the package requested by the user -
the sort of chain above could not ever be properly resolved in this
case.
Again, there isn't anything wrong with yum installing local packages.
It's the natural tool to do the job, and there isn't any compelling
reason to do otherwise. "Feels wrong" does not count as a compelling
reason, either. ;-)
So here's a compelling reason:
I've done a lot of work to make it so a user could 'import yum' and work
from there with all the packageSacks from repositories and have access
to the rpmdb.
But right now I'm fairly positive b/t the above requested features and
the AI that other people want yum to become to magically solve all
problems and tap you on the shoulder about it that I'm not going to have
time to do it.
I work on yum in my spare time, it's not part of what I'm paid to do in
my day job. So if there are considerable features people want to see
developed then they're going to need to put up some functional,
non-hacky code for it.
The api for yum is, right now, not stable and I'm not sure when it will
hit stability but I'm more than willing to talk about what people need
and try to make the yum module work even better as a simple module for
utility authoring.
so right now that's the limitation.
-sv
10:25 p.m.
Hmm... somhow using yum to install a local package feels wrong...
Hmm...
think ill acctually have to write some prototype stuff, then.
rpm-depsolve, here i come! :P
Always wanted to create some "core" utility...
yum install /some/path/to/an/rpm
yum looks for that file
if it can't find it, it exits and laughs at the user, as it should
be. :)
if it finds it then it reads in the header and other information and
makes a special local repository in memory for it.
it puts the package into a transaction set (just like a normal package)
and checks it. If it can't find a resolution it looks through the
repositories (as normal) and adds packages that do resolve it.
I've done some thinking about it recently and it's really not all that
special of a case. The trick is tracking the package state in a sane
manner for putting in the transaction.
-sv
2:17 a.m.
Hello Sean,
On Tue, 2004-09-07 at 21:19, Sean Middleditch wrote:
If you're alright with requesting a tool like
'rpm-depsolve', I don't
see at all how you can argue against just using yum. ;-)
Take a look at the man page for rpm and scan for --aid. You need to
setup the rpmdb for the dependencies to get resolved.
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
10:34 a.m.
ons, 08.09.2004 kl. 09.17 skrev Leonard den Ottolander:
Hello Sean,
On Tue, 2004-09-07 at 21:19, Sean Middleditch wrote:
> If you're alright with requesting a tool like 'rpm-depsolve', I
don't
> see at all how you can argue against just using yum. ;-)
Take a look at the man page for rpm and scan for --aid. You need to
setup the rpmdb for the dependencies to get resolved.
Leonard.
I did. But i don't understand what it means...
--aid Add suggested packages to the transaction set when needed.
--
mount -t life -o ro /dev/dna /genetic/research
12:09 p.m.
On Wed, 2004-09-08 at 11:34, Kyrre Ness Sjobak wrote:
> > If you're alright with requesting a tool like
'rpm-depsolve', I don't
> > see at all how you can argue against just using yum. ;-)
>
> Take a look at the man page for rpm and scan for --aid. You need to
> setup the rpmdb for the dependencies to get resolved.
I did. But i don't understand what it means...
--aid Add suggested packages to the transaction set when needed.
q.v. http://www.redhat.com/advice/tips/rhce/rpm.html
--
Paul W. Frields, RHCE
2:55 p.m.
On Mon, 2004-09-06 at 20:04 +0100, Rui Miguel Seabra wrote:
Well, I thought there was a process for package submission, review
and
what not. Of course accidents happen. But this is no excuse, or is a
"meta packager" like yum not better than plain rpm in itself?
As far as I can see, I have to solve about as many problems as I did
without a metapackager (--obsoletes, --exclude=..., etc...). The job of
a meta packager is making things easier.
This is, of course, assuming I already have the RPMS.
The automatic download of what's needed saves me a lot of time!
Thanks!
Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
5:32 p.m.
On Mon, 06 Sep 2004 20:04:06 +0100, Rui Miguel Seabra <rms(a)1407.org> wrote:
> just set obsoletes=1 in the [main] section of your yum.conf
Oh, I've already done that. I just think it should be the default.
I disagree. I would suggest instead of obsoletes being on by default
that if yum can detect an situation wher an obsolete operation could
be performaed when a conflict is detected yum should inform the user
in some way that activating obsoletes might be worth trying to resolve
the conflict ,becuase one of the invovled packages in the conflict has
non-empty obsolete tags.
Well, I thought there was a process for package submission, review
and
what not. Of course accidents happen. But this is no excuse, or is a
"meta packager" like yum not better than plain rpm in itself?
Whose to say all the possible obsoleting loop situations are accidents?
As far as I can see, I have to solve about as many problems as I did
without a metapackager (--obsoletes, --exclude=..., etc...). The job of
a meta packager is making things easier.
Are you talking about your experience with development and test
releases specifically, because if you are.. no tool is going to make
insanity of the development tree...sane.
Test releases eat babies... the development tree more so.
Easier...for clearly logical situations. Package tools should not take
action in ill-defined situations such as repository self-consistency
problems where excludes are needed.
It is arguable whether obsoletes as a class are ill-defined, circular
and/or chains of obsoletes definitely are.
Anyway, loops are not that hard to find, just mark where you've
been
previously (prolog 101) and handle apropriately (ie, until repo fixes
it, I can't do anything that touches foo, bar or baz, may I proceed with
the rest?).
I do not see how this is helpful overall. Are you suggesting yum hide
repository side problems from users by default? How is that helpful in
resolving those repository side problems? The safe thing to do, by
default, is when an error is encountered to inform the user of the
error and quit so that the user can decide to take appropriate action.
Automating
a loop that actives excludes for conflicts or dependancy errors does
nothing but help users ignore problems, instead of reporting them.
-jef
6:03 p.m.
On Mon, 2004-09-06 at 18:32 -0400, Jeff Spaleta wrote:
On Mon, 06 Sep 2004 20:04:06 +0100, Rui Miguel Seabra
<rms(a)1407.org> wrote:
> > just set obsoletes=1 in the [main] section of your yum.conf
>
> Oh, I've already done that. I just think it should be the default.
I disagree. I would suggest instead of obsoletes being on by default
that if yum can detect an situation wher an obsolete operation could
be performaed when a conflict is detected yum should inform the user
in some way that activating obsoletes might be worth trying to resolve
the conflict ,becuase one of the invovled packages in the conflict has
non-empty obsolete tags.
if one package obsoletes the other it's noted in the transaction by rpm.
So two conflicting packages that obsolete each other should be
acknowledged.
The problem in the case of rawhide recently was that
pkg1 obsoleted pkg2
but pkg2 was also up for an update.
so without the obsoletes in the calculation pkg1 was never even being
looked at but the new pkgs were conflicting.
Easier...for clearly logical situations. Package tools should not
take
action in ill-defined situations such as repository self-consistency
problems where excludes are needed.
It is arguable whether obsoletes as a class are ill-defined, circular
and/or chains of obsoletes definitely are.
This is why I've added the --obsoletes argument so the user can take
these actions on their own. Additionally the 'list obsoletes' option is
new. So you can see what from a repository will obsolete something on
your system. The output is not as good right now, it's on my short list
to make prettier.
-sv
6:45 p.m.
Well, I thought there was a process for package submission, review
and
what not. Of course accidents happen. But this is no excuse, or is a
"meta packager" like yum not better than plain rpm in itself?
As far as I can see, I have to solve about as many problems as I did
without a metapackager (--obsoletes, --exclude=..., etc...). The job of
a meta packager is making things easier.
it's not the job of the metapackagers to let potentially serious
problems go unseen. That's ridiculous.
That's like saying: My kernel shouldn't scream at me about hard drive
failures, it should quietly let them happen.
if there is a potential conflict that can't really be resolved, prompt
the user.
Anyway, loops are not that hard to find, just mark where you've
been
previously (prolog 101) and handle apropriately (ie, until repo fixes
it, I can't do anything that touches foo, bar or baz, may I proceed with
the rest?).
okay then define the procedure. Set up the standard for handling mutual
obsoleting packages and updates.
you write up the process for what has to occur and get EVERYONE to agree
on it and I'll write the code.
-sv
2:21 a.m.
On Mon, 2004-09-06 at 19:45 -0400, seth vidal wrote:
> Well, I thought there was a process for package submission,
review and
> what not. Of course accidents happen. But this is no excuse, or is a
> "meta packager" like yum not better than plain rpm in itself?
> As far as I can see, I have to solve about as many problems as I did
> without a metapackager (--obsoletes, --exclude=..., etc...). The job of
> a meta packager is making things easier.
it's not the job of the metapackagers to let potentially serious
problems go unseen. That's ridiculous.
What do you think of a security update that doesn't update because
there's a bug in an unrelated package?
How "potentially serious" a problem would that be?
The job of a metapackager is making updating easier, not harder just as
hard as if it wasn't there.
That's like saying: My kernel shouldn't scream at me about
hard drive
failures, it should quietly let them happen.
I fail to see a resemblance. I'm saying to not touch with the
problematic packages but try to keep on with the rest, if possible.
There would be a resemblance if I was saying to install even if it
screamed of a problem...
if there is a potential conflict that can't really be resolved,
prompt
the user.
Yum doesn't prompt. Barfs. You could be right if it did, but
_it_doesn't_.
You can handle it. Fine.
I can handle it. Fine.
But is it satisfying the purpose?
> Anyway, loops are not that hard to find, just mark where
you've been
> previously (prolog 101) and handle apropriately (ie, until repo fixes
> it, I can't do anything that touches foo, bar or baz, may I proceed with
> the rest?).
okay then define the procedure. Set up the standard for handling mutual
obsoleting packages and updates.
you write up the process for what has to occur and get EVERYONE to agree
on it and I'll write the code.
In a very highlevel way, I already did, wouldn't you say so?
You simple mark where you've been so far (and where you have had
problems), and check for those marks at each package.
A mutual obsolete is just another kind of loop.
There's no need to deny it from the start like you seem to be doing.
Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
7:05 a.m.
Hi Rui,
On Tue, 2004-09-07 at 09:21, Rui Miguel Seabra wrote:
What do you think of a security update that doesn't update
because
there's a bug in an unrelated package?
Firstly the fact that it interferes makes it related. Secondly it was
pointed out by more than one user that hiding details about conflicts
from the user (by skipping such packages) is probably worse than
erroring out with a message.
How "potentially serious" a problem would that be?
The user should have noticed there's a problem from the warnings (s)he
received. If (s)he can't deal with those (s)he shouldn't be using
multiple repos in the first place.
The job of a metapackager is making updating easier, not harder just
as
hard as if it wasn't there.
As pointed out the metapackager can not be expected to handle conflicts
if no standard on which all the repositories (and users) agree is
defined on how to do so.
In case of your above example, how should yum know it needs to skip the
package that holds the obsoletes, and not the package for which a
security update is released?
There would be a resemblance if I was saying to install even if it
screamed of a problem...
Well that is sort of what you suggest above. Install security update
even though there is a conflict and skip the other package. I still
don't see how that could solve a circular obsoletes by the way.
Yum doesn't prompt. Barfs. You could be right if it did, but
_it_doesn't_.
Seth already pointed out developer time is limited. Would you be so kind
to provide patches for more user friendly messages?
> you write up the process for what has to occur and get EVERYONE
to agree
> on it and I'll write the code.
In a very highlevel way, I already did, wouldn't you say so?
No. You might have indicated a problem that you perceive, but you have
neither described a standard on how to handle it, nor have you got
everyone to agree on your solution.
Leonard "you may feel a slight sting, that's pride fuckin' wit ya. Fuck
pride!" den Ottolander.
--
mount -t life -o ro /dev/dna /genetic/research
7:32 a.m.
On Tue, 2004-09-07 at 14:05 +0200, Leonard den Ottolander wrote:
On Tue, 2004-09-07 at 09:21, Rui Miguel Seabra wrote:
> What do you think of a security update that doesn't update because
> there's a bug in an unrelated package?
Firstly the fact that it interferes makes it related. Secondly it was
pointed out by more than one user that hiding details about conflicts
from the user (by skipping such packages) is probably worse than
erroring out with a message.
I never mentioned hiding, nor was that the intention.
> How "potentially serious" a problem would that be?
The user should have noticed there's a problem from the warnings (s)he
received. If (s)he can't deal with those (s)he shouldn't be using
multiple repos in the first place.
What multiple repos? Why do you suppose there have to be multiple repos
for this to happen?
The latest problem of barfing due to obsolete packages happened recently
with xorg.
> The job of a metapackager is making updating easier, not harder
just as
> hard as if it wasn't there.
As pointed out the metapackager can not be expected to handle conflicts
if no standard on which all the repositories (and users) agree is
defined on how to do so.
There's nothing about solving conflicts. Just not letting a conflict on
some packages affect the other unrelated (ie, those that do not depend
on them).
In case of your above example, how should yum know it needs to skip
the
package that holds the obsoletes, and not the package for which a
security update is released?
Huh? You're not understanding:
yum barfed because of obsolete packages.
if there was an unrelated security package, it wouldn't be applied
because yum barfed.
if, since there was a problem with some packages, it offered to
install the other unrelated ones, the problem would be minimized and
life would be made easier for the end user.
> There would be a resemblance if I was saying to install even if
it
> screamed of a problem...
Well that is sort of what you suggest above. Install security update
even though there is a conflict and skip the other package. I still
don't see how that could solve a circular obsoletes by the way.
No. You're misreading. Read again. I'm talking about a problem on an
unrelated package preventing an update, because obsoletes is not on by
default.
Imagine there was a bug with mount (which is suid root).
An update for util-linux wouldn't be upgraded on one of the last update
batches because some xorg-x11 packages obsoleted others, halting the
process.
As you can see, there is no X here:
[rms@roque ~]$ rpm -q util-linux --requires
/bin/sh
/bin/sh
/etc/pam.d/system-auth
/sbin/install-info
config(util-linux) = 2.12a-6
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.3)
libc.so.6(GLIBC_2.3.3)
libcrypt.so.1
libcrypt.so.1(GLIBC_2.0)
libdl.so.2
libncurses.so.5
libpam.so.0
libpam_misc.so.0
libpopt.so.0
libtermcap.so.2
libutil.so.1
libutil.so.1(GLIBC_2.0)
libuuid.so.1
libz.so.1
pam >= 0.66-4
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
> Yum doesn't prompt. Barfs. You could be right if it did,
but
> _it_doesn't_.
Seth already pointed out developer time is limited. Would you be so kind
to provide patches for more user friendly messages?
I'm not demaning it to be solved, I wondered why something wsn't the
default and I don't see any answer with a sensible reason. Just
"NOTABUG" or "WONTFIX".
All I read were excuses. I can understand limited time, not bad and
arrogant statements, like expecting a newbie to be able to solve yum
dependency problems.
> > you write up the process for what has to occur and get
EVERYONE to agree
> > on it and I'll write the code.
> In a very highlevel way, I already did, wouldn't you say so?
No. You might have indicated a problem that you perceive,
Not perceive. Exists. A newbie user is placed with a "difficult"
challenge unecessarily, and important packages may not be upgraded due
to certain bugs in unrelated packages.
And the excuse for not solving is not "limited time" (which I would
understand) but "WONTFIX" (not how the replies were written, but how
they "sounded" to my "ears").
but you have
neither described a standard on how to handle it, nor have you got
everyone to agree on your solution.
I don't need to describe in detail what's taught on classes about
finding paths on mazes without getting lost on loops, do I?
You mark where you have been, so that if you find it again, you know
you've been there.
You mark obsolete "paths" until you find one that's already registered
(a loop).
Anyway, I'm not complaining my self. I just think this is a bad thing
for newbie users. For me? It's just a minute (or so) more.
Leonard "you may feel a slight sting, that's pride
fuckin' wit ya. Fuck
pride!" den Ottolander.
I only hope this is a random quote or else, it is a very innadequate
one, I think.
Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
8:09 a.m.
What multiple repos? Why do you suppose there have to be multiple
repos
for this to happen?
The latest problem of barfing due to obsolete packages happened recently
with xorg.
The problem was with xorg in RAWHIDE. Not in a normal repository. If
people want to run rawhide then they can figure out some subset of
pkging problems that come up.
I added the obsoletes option to yum.conf so that people who feel
confident in obsoletes. I do not feel comfortable making obsoletes the
default. The last time there was a circular obsoletes in the core distro
was b/t zebra and routed. They each obsoleted each other.
I discovered the problem b/c I watched a system oscillate b/t the two
packages every other day.
What I'm asking for is how should yum track that? Do you want it to
maintain some state of what packages used to be installed outside of the
rpmdb? Should I create a secondary yumdb of obsoletes so I can know what
one was installed before the first obsoletes?
There's nothing about solving conflicts. Just not letting a
conflict on
some packages affect the other unrelated (ie, those that do not depend
on them).
We're not talking about conflicts - we're talking about obsoletes.
> In case of your above example, how should yum know it needs to skip the
> package that holds the obsoletes, and not the package for which a
> security update is released?
Huh? You're not understanding:
yum barfed because of obsolete packages.
if there was an unrelated security package, it wouldn't be applied
because yum barfed.
if, since there was a problem with some packages, it offered to
install the other unrelated ones, the problem would be minimized and
life would be made easier for the end user.
So you would like yum, in the event of an automated loop to print out an
error message but to do everything else in the transaction? This seems
like safe behavior to you?
Imagine there was a bug with mount (which is suid root).
An update for util-linux wouldn't be upgraded on one of the last update
batches because some xorg-x11 packages obsoleted others, halting the
process.
What about the inverse case?
yum can update trivial things but b/c of some issue can't update a
security related patch. Oh but wait, we have no metadata to tell us that
one patch is security and one isn't so we can't rank the updates.
The reason I error out on any package failing is to try to get the
attention of the user. Happily continuing will typically make the user
ignore it when they should probably be paying closer attention.
I'm not demaning it to be solved, I wondered why something
wsn't the
default and I don't see any answer with a sensible reason. Just
"NOTABUG" or "WONTFIX".
Where did I say either of those? I've asked, repeatedly, for the process
everyone agrees on as the best behavior in those situations and I've
gotten a general 'solve loops' response. No one has said:
Answer these questions:
In the event of a conflict what should occur?
In the event of a conflict with a -y specified?
In the event of an unresolvable dep?
In the event of an unresolvable dept with -y specified?
In the event of an obsoleting loop?
In the event of an obsoleting loop with -y specified?
If I'm going to write code that handles these cases I would love to get
some other people's input on the best way to handle it.
All I read were excuses. I can understand limited time, not bad and
arrogant statements, like expecting a newbie to be able to solve yum
dependency problems.
Where are the arrogant statements? I'm GENUINELY looking for expected
behavior.
> > > you write up the process for what has to occur and get
EVERYONE to agree
> > > on it and I'll write the code.
> > In a very highlevel way, I already did, wouldn't you say so?
>
> No. You might have indicated a problem that you perceive,
Not perceive. Exists. A newbie user is placed with a "difficult"
challenge unecessarily, and important packages may not be upgraded due
to certain bugs in unrelated packages.
And the excuse for not solving is not "limited time" (which I would
understand) but "WONTFIX" (not how the replies were written, but how
they "sounded" to my "ears").
Then get your ears checked. That's not what I've been saying. But I'll
be damned if I'm going to "fix" something which will make it equally bad
as if I hadn't.
I don't need to describe in detail what's taught on classes
about
finding paths on mazes without getting lost on loops, do I?
It's not about breaking loops. It's about expected behavior for pkging
conflicts or problems of various types. It's about handling automated
runs.
-sv
8:36 a.m.
Le mardi 07 septembre 2004 à 09:09 -0400, seth vidal a écrit :
> What multiple repos? Why do you suppose there have to be
multiple repos
> for this to happen?
>
> The latest problem of barfing due to obsolete packages happened recently
> with xorg.
The problem was with xorg in RAWHIDE. Not in a normal repository. If
people want to run rawhide then they can figure out some subset of
pkging problems that come up.
You have most of the problems of Rawhide on standard RHAS/Fedora
systemes. It may be less frequent, but usually you don't have the leeway
to fix it you get with a Rawhide box (entreprise critical, etc etc)
« It's in Rawhide, I can ignore it » has always been a poor excuse IMHO.
Cheers,
--
Nicolas Mailhot
9:06 a.m.
On Tue, 2004-09-07 at 09:36, Nicolas Mailhot wrote:
Le mardi 07 septembre 2004 à 09:09 -0400, seth vidal a écrit :
> > What multiple repos? Why do you suppose there have to be multiple repos
> > for this to happen?
> >
> > The latest problem of barfing due to obsolete packages happened recently
> > with xorg.
>
> The problem was with xorg in RAWHIDE. Not in a normal repository. If
> people want to run rawhide then they can figure out some subset of
> pkging problems that come up.
You have most of the problems of Rawhide on standard RHAS/Fedora
systemes. It may be less frequent, but usually you don't have the leeway
to fix it you get with a Rawhide box (entreprise critical, etc etc)
« It's in Rawhide, I can ignore it » has always been a poor excuse IMHO.
I completely disagree. Rawhide frequently has unresolvable dependencies.
It frequently has randomly introduced version updates that are rolled
back in the next rawhide update.
Those things, which catch something like 90% of the users, do not happen
in stable releases. They do happen in broken repositories though. But
I'm not sure that just continuing when a repository is broken is in
anyone's best interest.
-sv
9:17 a.m.
On Tue, 2004-09-07 at 09:09 -0400, seth vidal wrote:
> What multiple repos? Why do you suppose there have to be
multiple repos
> for this to happen?
>
> The latest problem of barfing due to obsolete packages happened recently
> with xorg.
The problem was with xorg in RAWHIDE. Not in a normal repository. If
people want to run rawhide then they can figure out some subset of
pkging problems that come up.
And I did figure.
But this is nothing that couldn't happen by accident on the stable tree.
I added the obsoletes option to yum.conf so that people who feel
confident in obsoletes. I do not feel comfortable making obsoletes the
default. The last time there was a circular obsoletes in the core distro
was b/t zebra and routed. They each obsoleted each other.
I discovered the problem b/c I watched a system oscillate b/t the two
packages every other day.
What I'm asking for is how should yum track that? Do you want it to
maintain some state of what packages used to be installed outside of the
rpmdb? Should I create a secondary yumdb of obsoletes so I can know what
one was installed before the first obsoletes?
Nothing so complicated. At each run one could keep a small graph of the
obsoletes, and test wether one is walking _again_ through some path.
> There's nothing about solving conflicts. Just not letting a
conflict on
> some packages affect the other unrelated (ie, those that do not depend
> on them).
We're not talking about conflicts - we're talking about obsoletes.
Ok, the pratical effects ends up being the same, I understand what you
mean by the difference. I was using the more general meaning of
conflict.
There's nothing about solving obsoletes. Just not letting an obsolete on
some package affect other unrelated packages (ie, those that do not
depend on them).
Is it clearer like this? Sorry for the terminology inadequacy...
> > In case of your above example, how should yum know it needs
to skip the
> > package that holds the obsoletes, and not the package for which a
> > security update is released?
>
> Huh? You're not understanding:
> yum barfed because of obsolete packages.
> if there was an unrelated security package, it wouldn't be applied
> because yum barfed.
> if, since there was a problem with some packages, it offered to
> install the other unrelated ones, the problem would be minimized and
> life would be made easier for the end user.
So you would like yum, in the event of an automated loop to print out an
error message but to do everything else in the transaction? This seems
like safe behavior to you?
If the other packages are unrelated (no dependency link), yes.
> Imagine there was a bug with mount (which is suid root).
> An update for util-linux wouldn't be upgraded on one of the last update
> batches because some xorg-x11 packages obsoleted others, halting the
> process.
What about the inverse case?
yum can update trivial things but b/c of some issue can't update a
security related patch. Oh but wait, we have no metadata to tell us that
one patch is security and one isn't so we can't rank the updates.
It's not even a matter of rank, the rank here was only to highlight what
I mean: unrelated packages should be safe to work on even if there's an
obsolete conflict somewhere else.
One can track obsoletes in order to avoid loops, is there a graph
library for python? I suppose so, but I'm not familiar with python,
sorry.
The reason I error out on any package failing is to try to get the
attention of the user. Happily continuing will typically make the user
ignore it when they should probably be paying closer attention.
I understand that, and that works fine on people who have bigger
experience with packages. I used to do this stuff "by hand", so I'm very
glad there's software like yum (which since 2.1 satisfies my "needs"
much more than it did before) and apt that help me on that.
> I'm not demaning it to be solved, I wondered why something
wsn't the
> default and I don't see any answer with a sensible reason. Just
> "NOTABUG" or "WONTFIX".
Where did I say either of those? I've asked, repeatedly, for the process
everyone agrees on as the best behavior in those situations and I've
gotten a general 'solve loops' response. No one has said:
Ok, I'm probably drawning meanings from interpretation, but I haven't
generally said solve loop. I've said that one should keep a log of loops
(and obsoletes loops) and when one is found see if anything can be done
with the rest before failing.
Answer these questions:
I'll answer considering the following terminology, please correct me
where I get it wrong:
conflict -> like two packages trying to own the same file
unresolvable dep -> self explanatory
obsolete loop -> self explanatory
In the event of a conflict what should occur?
I think that
those packages and those that depend on them should be
skipped, and try to work on with the rest.
In the event of a conflict with a -y specified?
Should there
even exist such a question to answer y? Assuming it
should...
... and considering the above terminology, I think it shouldn't work.
-y is a way to force an answer because you expect everything to be ok,
but in this case not only it isn't, it can have serious consequences.
But IMHO that question shouldn't exist.
In the event of an unresolvable dep?
In the event of an unresolvable dept with -y specified?
ditto for both
In the event of an obsoleting loop?
In the event of an obsoleting loop with -y specified?
ditto for both
If I'm going to write code that handles these cases I would love
to get
some other people's input on the best way to handle it.
I think that if some packages don't depend on the problematic packages,
the metapackager should try to see if he can work with them.
The only problem that could happen is very misbehaved packages (like,
not telling the truth about what they require).
> All I read were excuses. I can understand limited time, not bad
and
> arrogant statements, like expecting a newbie to be able to solve yum
> dependency problems.
Where are the arrogant statements? I'm GENUINELY looking for expected
behavior.
Not you specifically. I'm sorry if I haven't been specific enough to
describe the expected behaviour, I didn't have in mind what kind of
description you wanted. I hope my answers to your questions were
helpful.
Then get your ears checked. That's not what I've been saying.
I think I wrongly assumed some people were in the AUTHORS file.
My mistake.
But I'll
be damned if I'm going to "fix" something which will make it equally bad
as if I hadn't.
I understand. But consider this:
Yum is much, much better now. Consider me as someone who up until
recently _really_ preferred apt to yum, now they're pratically the same,
as far as I need a meta packager.
Since obviously apt is the preferred metapackager by FC maintainers at
the moment, I think the current minor differences are completely
irrelevant, and not being familiar with python it's better to suggest
how to solve the problems instead of just working around them.
So I'm a convert :) I'm just trying to incite yum into an even better
spot.
It's not about breaking loops. It's about expected behavior
for pkging
conflicts or problems of various types. It's about handling automated
runs.
I really hope my answers help.
Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
8:40 a.m.
Hi Rui,
On Tue, 2004-09-07 at 14:32, Rui Miguel Seabra wrote:
I never mentioned hiding, nor was that the intention.
So how would you make such a failure stand out in an otherwise
successful update? Example: Critical update was skipped because a
dependency issue. Newbie: "Oh, it's just a warning as the program
completed successfully." This is not more or less valid than the
examples you give.
What multiple repos? Why do you suppose there have to be multiple
repos
for this to happen?
The latest problem of barfing due to obsolete packages happened recently
with xorg.
You are correct that I make a bit of an assumption, but in stable
distribution trees such conflicts should be seldom and if they do exist
it's fine newbies start crying for help as there is obviously something
wrong with the tree.
Huh? You're not understanding:
yum barfed because of obsolete packages.
if there was an unrelated security package, it wouldn't be applied
because yum barfed.
Indeed the packages are unrelated. But...
As you can see, there is no X here:
[rms@roque ~]$ rpm -q util-linux --requires
That might be so, but what makes you so sure hiding the xorg-x11
packages won't cause other updates to fail in the process?
I'm not demaning it to be solved, I wondered why something
wsn't the
default and I don't see any answer with a sensible reason. Just
"NOTABUG" or "WONTFIX".
"Not a bug" is quite different from "won't fix".
All I read were excuses. I can understand limited time, not bad and
arrogant statements, like expecting a newbie to be able to solve yum
dependency problems.
The dependency problems are not in yum but in the tree(s).
> > > you write up the process for what has to occur and get
EVERYONE to agree
Not perceive. Exists. A newbie user is placed with a
"difficult"
challenge unecessarily, and important packages may not be upgraded due
to certain bugs in unrelated packages.
Ok. But you perceive this to be a yum issue instead of a repo issue. And
you still don't answer the essential part, namely give us a definition
of how yum should behave in case of conflicts. Just skipping packages
might cause unexpected side effects.
> but you have
> neither described a standard on how to handle it, nor have you got
> everyone to agree on your solution.
I don't need to describe in detail what's taught on classes about
finding paths on mazes without getting lost on loops, do I?
Cute. If it's so obvious to you you might want to come up with a patch
so we can evaluate it. But iirc your first proposal was just to toggle a
switch, which doesn't cut it.
You mark where you have been, so that if you find it again, you know
you've been there.
You mark obsolete "paths" until you find one that's already registered
(a loop).
How would the entry point in that path (assuming a circular obsoletes
situation) influence which package gets installed or removed?
Anyway, I'm not complaining my self. I just think this is a bad
thing
for newbie users. For me? It's just a minute (or so) more.
As pointed out these issues will hardly exist in single distribution
repositories (they shouldn't).
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
9:04 a.m.
On Mon, 2004-09-06 at 08:24 +0200, Hans de Goede wrote:
Hi,
I just tried the new yum (from rawhide) and it works great! Much much
better then the old stuff, does this mean I can nuke all headers from
the yum cache now?
sure.
Are any livna developers on this list? livna needs to be updated to
the
new format :), so does macromedia.mplug probably.
livna has the repodata.
-sv
10:06 a.m.
seth vidal wrote:
On Mon, 2004-09-06 at 08:24 +0200, Hans de Goede wrote:
>Hi,
>
>I just tried the new yum (from rawhide) and it works great! Much much
>better then the old stuff, does this mean I can nuke all headers from
>the yum cache now?
sure.
EXCELLENT!
>Are any livna developers on this list? livna needs to be updated to the
>new format :), so does macromedia.mplug probably.
>
livna has the repodata.
-sv
Since when? yesterday I got an error (using the 2.90 tree)
Regards,
Hans
6:47 p.m.
Since when? yesterday I got an error (using the 2.90 tree)
since a few days ago.
http://rpm.livna.org/fedora/2/i386/RPMS.stable/
-sv
8:56 p.m.
On Mon, 06 Sep 2004 19:47:51 -0400, seth vidal <skvidal(a)phy.duke.edu> wrote:
> Since when? yesterday I got an error (using the 2.90 tree)
>
since a few days ago.
http://rpm.livna.org/fedora/2/i386/RPMS.stable/
ah... he's trying to use 2.90 tree.. which doesnt even actually exist.
-jef"move along...nothing to see here"spaleta
2:15 a.m.
Jeff Spaleta wrote:
On Mon, 06 Sep 2004 19:47:51 -0400, seth vidal
<skvidal(a)phy.duke.edu> wrote:
>>Since when? yesterday I got an error (using the 2.90 tree)
>>
>
>since a few days ago.
>http://rpm.livna.org/fedora/2/i386/RPMS.stable/
ah... he's trying to use 2.90 tree.. which doesnt even actually exist.
-jef"move along...nothing to see here"spaleta
Ehm
Oops that was a mistake I was ofcourse using the 2 tree, since as you
say there is no 2.90 tree :)
But the probem was that I was using:
baseurl=http://rpm.livna.org/fedora/2/$basearch/yum/stable
Instead of:
baseurl=http://rpm.livna.org/fedora/2/$basearch/RPMS.stable
This because when I made my yum.conf livna hadn't move to the new naming
scheme yet.
Thanks for showing me the problem.
Regards,
Hans
--
EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es
1:37 p.m.
--On Sunday, September 05, 2004 10:17 PM -0400 seth vidal
<skvidal(a)phy.duke.edu> wrote:
1. Yum will no longer work with repositories generated with
yum-arch.
The new format and the old format do not conlict with each other so
if you want to run createrepo and yum-arch on a single repository
that will work just fine. However, the new yum will not support
old-style repositories and there are no plans at this time to make
it possible.
Which well-known repositories have the new metadata? Fedora base, update,
development, testing? Dag? AT?
3:59 p.m.
On Mon, 2004-09-06 at 11:37 -0700, Kenneth Porter wrote:
--On Sunday, September 05, 2004 10:17 PM -0400 seth vidal
<skvidal(a)phy.duke.edu> wrote:
> 1. Yum will no longer work with repositories generated with yum-arch.
> The new format and the old format do not conlict with each other so
> if you want to run createrepo and yum-arch on a single repository
> that will work just fine. However, the new yum will not support
> old-style repositories and there are no plans at this time to make
> it possible.
Which well-known repositories have the new metadata? Fedora base, update,
development, testing? Dag? AT?
Both Dag and Freshrpms are using the new metadata.
--
Ricardo Veguilla <veguilla(a)hpcf.upr.edu>
7163
days inactive
7165
days old
40 comments
14 participants
participants (14)
-
Hans de Goede -
Jef Spaleta -
Kenneth Porter -
Konstantin Ryabitsev -
Kyrre Ness Sjobak -
Leonard den Ottolander -
Naoki -
Nicolas Mailhot -
Panu Matilainen -
Paul W. Frields -
Ricardo Veguilla -
Rui Miguel Silva Seabra -
Sean Middleditch -
seth vidal