Kind request: fix your packages

[Michael Schwendt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 03 Oct 2003 10:11:46 -0400, Sean Middleditch wrote:

> > > Right.  But then you still can't detect errata packages and such when
> > > building based only on /etc/release.
> > 
> > Not necessary, because errata packages are backported fixes, not
> > feature upgrades.
> 
> Not in Fedora.  It's been mentioned several times on the list, and on
> the site iirc, that security updates will simply be new packaged
> versions of the upstream packages.

Deadlock. I've commented on that earlier. Do you realize that when you
fix security bugs with the release of new software versions it can
make it necessary to rebuild dependencies? Whether or not that will be
required depends on how compatible the new software version is (with
regard to API and ABI, but also wrt details such as userspace file
locations).

> > It's the packager's (distributor's) responsibility to
> > provide a working set of dependencies. Those people, who send newbies
> > to rpmseek.com where the newbies chooses a prebuilt package for an
> > arbitrary distribution and fails to locate missing dependencies, are
> > nuts and are not helpful. It is much more helpful to point newbies to
> > repositories and tools like Synaptic.
> 
> The only reason its "nuts" is because packages are made with no thought
> of real users.  It shouldn't have to be nuts.  It should just up and
> work.

Impossible mission. An individual package will never know *where* to
get dependencies. It only knows *what* is missing. However, if the
user makes use of package tools, the problem is solved. Back to your
example, of a package requiring libfoo.so.23.4.6 (or similar), it will
be entertaining to make the newbie understand that the file is
provided by package libfoo-1.0 and not libfoo-0.9 or libfoo-2.0.

> My point is, if you need to get a new library, it should *never* break
> anything.  It's either compatible, in which case its a waste of time to
> rebuild packages for it, or its not compatible, in which case you'd need
> to modify the code for the app and release a new version, which isn't a
> packaging issue.

Returning to backporting security-fixes in libraries, eh? Another loop
in this discussion. It all boils down to feasibility of doing version
upgrades of core components.

> A single source set *can* be made into several RPMs.

Happens often.

> I'm not sure how
> well RPM supports file over-rides, but some clever packaging could avoid
> the problem for users even when the app was designed by someone who
> enjoys watching users cry.  ;-)

Still, the app doesn't build if its build requirements aren't
satisfied. Another loop in the discussion.

> As you've noted, users can always install dependencies.  So can
> developers.  Developers are probably more capable of it.  So your
> package depends on something only in RH8+, but you want it to work in
> RH7 too?  Just depend on the devel files for the newer version.  People
> building on RH7 can grab it and build on in bliss, and you as a packager
> don't need to waste time making silly hacks.  ^,^

With current tools and implementation of explicit versioned build
requirements, that would cause the application to not build at all on
an unmodified RH7 unless the src.rpm examines in detail what's there
and what's not. Maybe we should go back to the early mails and restart
there. ;)

> > This doesn't change a thing. The case we're discussing is a new app
> > which uses the new API and doesn't build with the old API. It requires
> > the new app to be backwards compatible, too, i.e. to use the old
> > deprecated API. And at some point in time, the API user needs to
> > switch to the current interface, because the old API is dropped.
> 
> Eh?  This is not at all how this works...  take a look at the GNOME
> libraries.  GNOME2.4 libs support GNOME2.0, GNOME2.2, and GNOME2.4
> interfaces.  An app made for GNOME2.0 runs just fine on GNOME2.4, altho
> an app written for GNOME2.4 may make use of the newer versions of the
> APIs, and thus not run on 2.0 or 2.2. 

Only the latter case is relevant to this discussion. Assume parts of
the app require GNOME 2.4, but the main part of the app doesn't depend
on GNOME 2.x at all. The app will build and run everywhere except for
the part that requires GNOME 2.4. Now make a package for all known
target platforms, which builds automatically and enables/disables
optional features depending on what build requirements are available.
The fun starts when this requires more than simple checks of installed
package versions (as outlined earlier).

> RPM Dependency hell exists from two things - dependencies that never
> work out, because poorly made packages make it so some apps need one
> version, and other apps need another version, resulting in a situation
> where its impossible to install both sets of apps without rebuilding
> everything.

Bring it to the point: _poorly made packages_, not just due to
versioned dependencies, but also due to custom and distribution
specific package names.

> This is something where I'd *love* to see an "official" RPM packaging
> policy similar to Debian.  Debian isn't perfect by a long shot, but even
> with their 3,000+ packagers and 10,000+ packages they manage to avoid a
> lot of these problems, and that's including not only Debian, but all the
> highly modified Debian-based offsprings as well.  it's not because dpkg
> is magic, but just because the packages are (usually) very well built.

This would be good, but would require the major distributors to
collaborate and adhere to such packaging policies also at the level of
what compiler version to use and when to package what software
versions. Sounds like impossible mission again. ;) There are more
major distributions which use RPM, and which are not derived from
eachother, than minor Debian derivatives.

- -- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD4DBQE/fZd10iMVcrivHFQRAkjZAJinTgHKhDsT7caqu0EUqmA3fIZHAJ9LT6o/
xjIfdBmrazD4sHk8iUd3XQ==
=6px4
-----END PGP SIGNATURE-----