Kind request: fix your packages

Fri Oct 3 14:11:46 UTC 2003

On Fri, 2003-10-03 at 09:41, Michael Schwendt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thu, 02 Oct 2003 21:49:23 -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.  If the only security update for a
package involves a bunch of other changes as well, then you get those as
well.

> 
> > > This seems to refer to prebuilt (binary) packages and is an entirely
> > > different matter.
> > 
> > This then might be a source of our disagreement - I couldn't care less
> > abotu building packages, I only care about the actual users installing
> > them.  ;-)
> 
> Doesn't matter. 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.

It's definitely possible to do, if people bother putting forth the
effort instead of taking the cheap way out packaging.  Take a look at
the autopackage system, its rather amazing, and is sort of working proof
that it's possible.  ~,^

> > Which is silly.  If a library/component is upgraded, it must either be
> > binary compatible (and thus not need rebuilt applications) or be
> > co-installable (in which case a backported fix for the old library would
> > be mandatory for a secure OS, but that's life.)
> 
> That contradicts itself. Why would you leave around the old library
> version if there is security hole in it? No need to keep the old one
> and co-install the new one. The security hole must be fixed, no matter
> how. Whether fixes are backported or applied as version upgrades, is a
> matter of feasibility.

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.

> 
> > If you really want to have to rebuild the system everytime the user
> > coughs, perhaps you should be using Gentoo instead of Fedora... ;-)
> 
> You're exaggerating. Smiley noted.

Yes, but only slightly :P

> 
> > > > If the software can use aspell, but has a switch to disable it, the
> > > > software is badly designed, because it creates an unfavorable
> > > > situation.
> > > 
> > > Why? Assume aspell support is truely optional.
> > 
> > Because it's completely insane to have to reinstall a whole different
> > version of the app to 'enable' a feature. 
> 
> Depends on whether this "aspell support" is a completely separate 
> plug-in or whether it is tied into the application. In either case, it
> likely comes together with the source code for the application and is
> built from within the same src.rpm. If the target platform doesn't
> suffice, you can either disable optional features or not build the app
> at all.

This is honestly something more in the realm of application design that
packaging, I'll admit - packagers shouldn't encourage sloppy design,
tho.  ;-)

A single source set *can* be made into several RPMs.  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.  ;-)

> 
> > It's a lot less to do with
> > technically possible or code correct, and a lot more to do with just it
> > being a completely stupid way to design anything.  If it's optional,
> > make it a plugin or add-on, not something that conditionally built into
> > or outof the app.
> 
> See above. You can only build that feature if build requirements are
> met.

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

> 
> > [...] But then, as a library author, if you know you have tons
> > of apps depending on your ABI, it's rather good form to go thru the
> > extra effort to keep it stable.  You can add newer API's without
> > removing old, and flush the deprecated stuff out every several releases,
> > and move the soversion up while you're at it. 
> 
> 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.  Older APIs are deprecated in
newer releases, meaning they are still available, but generate warning
when used.  When GNOME3.0 comes out, all the deprecated APIs will be
dropped - older apps can simply depend on the GNOME2.x libs, which will
be coinstallable with GNOME3 (just like GNOME1.x apps can depend on
GNOME1.x libs, which are co-installable with GNOME2).

This is all just sane development practice.  There is nothing stopping
people from doing this other than ignorance and sloth.  ;-)

> 
> > You can have a pre-1.0
> > app with a soversion of 23.4.6; the soversion has *nothing* to do with
> > release version of stability, only with interface version.
> 
> Tell that the typical rpm-dependency-hell troll. ;o)

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.

The second situation is lack of an easy way to get dependencies; RH/FC
has up2date, with up2date servers, apt servers, and yum servers.  Those
solve the second problem, assuming they don't make the first problem
worse - which can only be solved by good packaging policies.

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.

> 
> - -- 
> Michael, who doesn't reply to top posts and complete quotes anymore.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> 
> iD8DBQE/fXyl0iMVcrivHFQRAkpgAJ9c4RcluvA0ig6LrlXqWmsokoMo8wCdHQd3
> 9d8XAAJtG9QdugqdUyFQBEw=
> =fmQY
> -----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.