-----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-----