Kind request: fix your packages

Fri Oct 3 16:04:35 UTC 2003

On Fri, 2003-10-03 at 11:36, Michael Schwendt wrote:
> -----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).

I agree backported fixes would be absolutely great, but if they're not
available...

It really falls on upstream to handle this in any case.  If you release
a buggy library 0.1 and later on have a 0.3 that fixes a security hole
you found, if people are using 0.1 its upstreams responsibility to
release 0.1b (or whatever).  In which case, packaging goes on as before,
with two versions of the library packaged, and apps never need worry
about it.

In the event the library is incompatible and no backported fixes are
available, the app needs a *code change*, which is no longer a packaging
problem, it's an upstream problem with the application itself.  A new
release of the app that compiles with the new lib would of course result
in a whole new package and new version, which would then be available as
an upgrade.

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

Nonsense, package networks already exist today.  I almost never manually
download individual dependencies anymore.  Let the package network tool
handle the dependency fetching.

It's also useful to use user-visible names and not cryptic release
names.  If the packager had sane errors like "You need Version 2.0 of
LibFoo", the user could easily find on the lib's website "Version 1.0
packages, Version 2.0 packages, and Version 3.0 packages."  Certainly
not always the case, but that doesn't mean the packager should throw up
his hands and give up hope.  ;-)

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

I've gone over this already; if I haven't made my point here yet, then I
give up.

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

So satisfy it.  The developer can fricken download the dependency. 
Problem solved.  If the person building the package can't download the
dependency, what in the nine hells is he doing building packages?  ;-)

> 
> > 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. ;)

The problem needs to be fixed in RPM then, and not have Fedora let you
continue hacking around the problem using etc/release.  Like I said the
first around, *fix the problem*, don't fix the *hack* for the problem.

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

Again, optional fetures should *never* be compile time.  That's
horrible, broken design, and any app doing that has no business being
ona  user's desktop to begin with.  Compile the app will all features
turned on, and the users can just install the dependencies.  Otherwise,
the app is broken from a user perspective.  You really need to start
looking at this from a users' point of view, and not a easily-packaged
point of view.  ;-)

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

Which is also horrible, now that you mention it - see my comment below
about policy.  ^,^

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

Don't just assume that's impossible.  It hasn't been tried to my
knowledge, which is the only reason anyone can claim so far that its
failed.  ;-)

Other things can be glossed over to a degree.  Compiler version really
(mostly) only affected C++ stuff, and that's history now.  Yes, it
sucks, and yes, older distro releases are rather screwed, but then
Fedora isn't about legacy cruft, it's about moving forward.  If we worry
about how screwed up the compiler ABI was, versus how its now standards
comformant, we might as well also start worrying about the old lib5
stuff too - better make sure all our software compiles/runs with it! 
Someone might be using Red Hat 4!  ;-)

(one might argue that if the ABI of core libs like libstdc++, or glibc,
changes, it's no longer the same base platform.  we're not just talking
about 'linux', where're talking about the platform made by
'linux/processor/corelibs', such that linux on x86 w/ an old lib ABI is
as different from linux on x86 w/ the new ABI as it is with Solaris on
SPARC - there's no avoiding the need for different packages then, no
matter how much it sucks.  ~,^)

> 
> - -- 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> 
> iD4DBQE/fZd10iMVcrivHFQRAkjZAJinTgHKhDsT7caqu0EUqmA3fIZHAJ9LT6o/
> xjIfdBmrazD4sHk8iUd3XQ==
> =6px4
> -----END PGP SIGNATURE-----
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.