major libgda and libgnomedb upgrade notice

Ralf Corsepius rc040203 at freenet.de
Mon Nov 28 15:18:37 UTC 2005


On Mon, 2005-11-28 at 09:27 -0500, Jeff Spaleta wrote:
> On 11/28/05, Ralf Corsepius <rc040203 at freenet.de> wrote:
> > You can: Ship compat packages.
> 
> and then orphan them a week later?
No, such packages would have to stay until ETA of a distribution,
because a package maintainer has no possibility to know what others are
doing with it.

Think about it: It's same rationale why RH can't upgrade GNOME, KDE, GCC
or glibc during a distribution's life-time.

> Since there are no guidelines for how long someone is required to hold
> maintainership over a package in general... i think your insistence
> for this single case is misplaced. 
No, I am only demand maintainers to do a reasonable job.

> This is the price that is paid for
> having a rolling model without distinct releases.   It's inapporpriate
> to force a packager to maintain compat packages for a time period
> beyond what they feel comfortable maintaining securely on their own.

1. Then, they should not upgrade a package.

2. Maintainers only _feel_ comfortable, but they never can be sure about
it.

> It irrational to believe that all versions of all libraries can be
> maintained forever into the future.
Nobody demanded this. 

For packages of no general importance, the brute force way of replacing
them works, but the more important a package is, the more likely such
kind of breakdowns is ... in some cases, maintainers will not be able to
avoid having to provide compat-runtime-packages, in some extremal cases
maintainers will not be able to avoid providing parallel installable
packages - Responsible maintainers will probably resort to not upgrading
a package in such cases.

Hans apparently vastly underestimated the impact of his directfb commit
(http://buildsys.fedoraproject.org/build-status/job.psp?uid=1292)
and now seems to be about to be committing the same mistake again.

>   Extras has never promised to be a
> static platform for development.

Nobody is wanting it to be static - But I want it stable!

The situation FE+Livna currently is, to me is beyond reason and
unacceptable:
...
-> Populating transaction set with selected packages. Please wait.
---> Package directfb.i386 0:0.9.24-4.fc4 set to be updated
---> Package mplayer-gui.i386 0:1.0-0.lvn.0.29.pre7try2.4 set to be
updated
---> Package mplayer.i386 0:1.0-0.lvn.0.29.pre7try2.4 set to be updated
---> Package mplayer-mencoder.i386 0:1.0-0.lvn.0.29.pre7try2.4 set to be
updated
--> Running transaction check
--> Processing Dependency: libsysfs.so.1 for package: directfb
--> Processing Dependency: libdirect-0.9.so.22 for package: xine-lib
--> Processing Dependency: libfusion-0.9.so.22 for package: xine-lib
--> Processing Dependency: libdirectfb-0.9.so.22 for package: xine-lib
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package sysfsutils.i386 0:1.2.0-4 set to be updated
--> Running transaction check
--> Processing Dependency: libdirect-0.9.so.22 for package: xine-lib
--> Processing Dependency: libfusion-0.9.so.22 for package: xine-lib
--> Processing Dependency: libdirectfb-0.9.so.22 for package: xine-lib
--> Finished Dependency Resolution
Error: Missing Dependency: libdirect-0.9.so.22 is needed by package
xine-lib
Error: Missing Dependency: libfusion-0.9.so.22 is needed by package
xine-lib
Error: Missing Dependency: libdirectfb-0.9.so.22 is needed by package
xine-lib

Livna has rebuilt mplayer, but hasn't update xine-lib, yet.

> And that's an argument you need to have with the steering
> committee.
FESCO still doesn't have an email address ;)

Ralf





More information about the fedora-extras-list mailing list