[repo-coord] Re: Latest apt broken?

[Axel Thimm]

I just upgraded tons of packages on my FC3 box with apt-get; among the
new packages, there was a new apt-get version. Unfortunately, it seems
# apt-get update
Fetching list of repositories/mirrors...
# apt-cache policy apt
Fetching list of repositories/mirrors...
E: could not open package priority file /etc/apt/rpmpriorities
Should I downgrade apt? Anything I should fix? There was only one
.rpmsave file on /etc/apt dir, and it did not contain anything relevant
to the problem at hand...

What version of apt-get are you running now ? What apt-get where you
running before ? I assume you went from one apt package from one
repository to an incompatible apt package from another repository.
Maybe you added a new repository ?
I know Axel removed most config-files necessary to run Apt from the apt
package and his package is prefered because he does not reset release
numbers anymore, so it is very likely this happened to you.

No, that's certainly not ATrpms' apt. The apt in ATrpms does have the
config files broken out to allow for any repo to supply its own, but
of course it has file dependencies on the config files, so this
situation is not possible unless you force the package to be installed
with rpm --nodeps.

From the "mirrors" reference I would assume Panus apt
(fedora.us/livna/extras?), which has some lua scripts to do choose
mirrors from some list.

It shouldn't be, nevertheless it happened. I cannot possibly prevent this
from happening.

A nice thing would be to agree on common infrastructure packages, and
breaking out the config files makes them vendor/repo neutral, so I
hope this does have a chance to be accepted in the long run (not that
we will be living to see it, but you have to plane in big timescales ;)

[Dag Wieers]

Post by Axel Thimm

E: could not open package priority file /etc/apt/rpmpriorities
Should I downgrade apt? Anything I should fix? There was only one
.rpmsave file on /etc/apt dir, and it did not contain anything relevant
to the problem at hand...

I know Axel removed most config-files necessary to run Apt from the apt
package and his package is prefered because he does not reset release
numbers anymore, so it is very likely this happened to you.

No, that's certainly not ATrpms' apt. The apt in ATrpms does have the
config files broken out to allow for any repo to supply its own, but
of course it has file dependencies on the config files, so this
situation is not possible unless you force the package to be installed
with rpm --nodeps.

Sorry Axel, I jumped to conclusion when I saw rpmpriorities missing and
your SPEC file did not have it. I did not see the dependencies to
%{_sysconfdir}/apt/... as I was looking for atrpms-package-config.
Possibly the late night hour was partly to blame.

Post by Axel Thimm
From the "mirrors" reference I would assume Panus apt
(fedora.us/livna/extras?), which has some lua scripts to do choose
mirrors from some list.

Yes, that makes much more sense.

Post by Axel Thimm

It shouldn't be, nevertheless it happened. I cannot possibly prevent this
from happening.

A nice thing would be to agree on common infrastructure packages, and
breaking out the config files makes them vendor/repo neutral, so I
hope this does have a chance to be accepted in the long run (not that
we will be living to see it, but you have to plane in big timescales ;)

Yes, I agree, but how would that work for
/etc/apt/{apt.conf,preferences,rpmpriorities} ? The atrpms-package-config
includes this. If I do the same, both will conflict again.

Again, sorry for the misinformation, I will be more wary in the future
about such things.

-- dag wieers, ***@wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]

[Axel Thimm]

Post by Dag Wieers

Post by Axel Thimm

E: could not open package priority file /etc/apt/rpmpriorities

I know Axel removed most config-files necessary to run Apt from the apt
package [...]

No, that's certainly not ATrpms' apt. The apt in ATrpms does have the
config files broken out to allow for any repo to supply its own, but
of course it has file dependencies on the config files, so this
situation is not possible unless you force the package to be installed
with rpm --nodeps.

Sorry Axel, I jumped to conclusion when I saw rpmpriorities missing and
your SPEC file did not have it. I did not see the dependencies to
%{_sysconfdir}/apt/... as I was looking for atrpms-package-config.
Possibly the late night hour was partly to blame.

No problem. There is indeed no direct reference to
atrpms-package-config or medley-package-config, only the file
dependencies on a package providing these. So anyone can craft a
my-repo-package-config and use this instead.

Post by Dag Wieers

Post by Axel Thimm
A nice thing would be to agree on common infrastructure packages,
and breaking out the config files makes them vendor/repo neutral,
so I hope this does have a chance to be accepted in the long run
(not that we will be living to see it, but you have to plane in
big timescales ;)

Yes, I agree, but how would that work for
/etc/apt/{apt.conf,preferences,rpmpriorities} ? The
atrpms-package-config includes this. If I do the same, both will
conflict again.

That's not a problem, I have three packages of this kind in ATrpms
(one is Fedora Core alone, one is Fedora Core with ATrpms, and one is
Fedora Core with everything but fedora.us, the so called "medley of
repos").

The only cumbersome thing is that these packages need to Conflict:
each other at the package level, otherwise they do so at file level
which is too late for apt to intervene. Works well if there are a
handfull of them but does not scale well. Perhaps smart deals better
with file conflicts (e.g. auto-promotes them to Conflicts:) and
behaves better, but I haven't tested.

It's not a perfect solution, but having the config out of the packages
is already a good step forward.

[Jeff Pitman]

Post by Axel Thimm
Works well if there are a
handfull of them but does not scale well. Perhaps smart deals better
with file conflicts (e.g. auto-promotes them to Conflicts:) and
behaves better, but I haven't tested.

Interesting RFE to be aware of:
https://bugzilla.redhat.com/beta/show_bug.cgi?id=131181

Implemented in 4.4. (I think; haven't tested, yet.)

Although, maybe off-topic for this thread, but Obsoleting
directories/files eases packager's effort in determining what names
have been used before (twisted, Twisted, python-Twisted,
python-twisted) and just Obsolete the provided dir which will nuke
whatever existing packages are there. Likewise, the repo-config
packages could use similar methods in the future. (FC4+, I guess.)

have fun,

[seth vidal]

Post by Jeff Pitman

Post by Axel Thimm
Works well if there are a
handfull of them but does not scale well. Perhaps smart deals better
with file conflicts (e.g. auto-promotes them to Conflicts:) and
behaves better, but I haven't tested.

https://bugzilla.redhat.com/beta/show_bug.cgi?id=131181
Implemented in 4.4. (I think; haven't tested, yet.)
Although, maybe off-topic for this thread, but Obsoleting
directories/files eases packager's effort in determining what names
have been used before (twisted, Twisted, python-Twisted,
python-twisted) and just Obsolete the provided dir which will nuke
whatever existing packages are there. Likewise, the repo-config
packages could use similar methods in the future. (FC4+, I guess.)

And yet it makes the pkg mgmt a nightmare b/c now, instead of being able
to key on file name I have to go find the packages the provide that file
(or worse yet, if wildcards are involved) then figure out the arch for
those involved and match.

oh yah - gonna be a party rewriting the obsoletes parser.

-sv

[Jeff Pitman]

Post by seth vidal
And yet it makes the pkg mgmt a nightmare b/c now, instead of being
able to key on file name I have to go find the packages the provide
that file (or worse yet, if wildcards are involved) then figure out
the arch for those involved and match.

How do you do "Requires: /usr/sbin/alternatives" ? I didn't think
wildcards were involved .. can't see an immediate use for that.
Explicit is better than implicit on this one.

[Axel Thimm]

Post by Jeff Pitman

Post by seth vidal
And yet it makes the pkg mgmt a nightmare b/c now, instead of being
able to key on file name I have to go find the packages the provide
that file (or worse yet, if wildcards are involved) then figure out
the arch for those involved and match.

How do you do "Requires: /usr/sbin/alternatives" ? I didn't think
wildcards were involved .. can't see an immediate use for that.
Explicit is better than implicit on this one.

I believe Seth is talking about implementing this behaviour in yum
(e.g. how a package resolver is going to traverse all packages to see
which ones provided this file to kick out).

It is in principle similar to the Requires seek, only that there a
package resolver can stop at the first match, which in the case of
Obsoletes/Conflicts it has to check everything.

Also wildcards make little sense for requires, but can be used for
Obsoletes/Conflicts (e.g. kde.spec could contain Obsoletes:
/usr/bin/gnome-* and vice versa ;).

From a packager's POV the more expressive power rpm gets the better :)

[Jeff Pitman]

Post by Jeff Pitman

Post by seth vidal
And yet it makes the pkg mgmt a nightmare b/c now, instead of being
able to key on file name I have to go find the packages the provide
that file (or worse yet, if wildcards are involved) then figure out
the arch for those involved and match.

How do you do "Requires: /usr/sbin/alternatives" ?

Perhaps a dict based on input from filelists.xml.gz would be
appropriate. The dict would use the filename as the key and the value
is the <package name="XXX">. Not sure how long it'd take on large repos
to create a dict, possibly pickling it for caching purposes, etc.

Wildcard lookup would be another enjoyable coding experiment. Wonder if
there are any recipes that might be applicable. (If the cache was
sqlite based, could use "like" or whatever...)

Anyway, I don't think it'll be too tough to code. Since, mainly it's to
display what packages are gonna get nuked. Problem is what's the speed
factor?

See what happens...