Kind request: fix your packages

Fri Oct 3 20:39:48 UTC 2003

On Fri, 2003-10-03 at 16:11, Michael Schwendt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Fri, 03 Oct 2003 14:28:42 -0400, Sean Middleditch wrote:
> 
> > Reading back a little ways, I'm now rather confused what your whole
> > paragraph was about - we have the tools/networks, so newbies don't have
> > to worry about libfoo-1.0 vs libfoo-0.9 and so on.
> 
> Let's see. Quoting you:
> >
> > Users should just be able to grab any package online they want,
> > and install it. 
> 
> Do you see rpm-dep-hell complaints from apt/yum/up2date users?
> I don't. But rpmfind.net/rpmseek.com users complain regularly.
> This is the context of the reply to your comment.

Ah, you mean tools that don't grab dependencies on install.  Those are a
pain, aren't they?  Whether you do "apt-get install foo" or "apt-get
install ./foo.i386.rpm", either way depends should be grabbed and the
package installed.  Should be, anyways, they probably don't, do they? 
(that 30 second memory is kicking in again ;-)

> 
> > No, your packaging method wants to screw over users, by making packages
> > that are not easy or sane to use, as the features and dependencies
> > present end up being based on silly things like where the packager built
> > them, versus the place the user is installing them.
> 
> Far from it. The binary packages are easy to use while the src.rpms
> may need a few adjustments (sort of --define value) before they adapt
> to altered build environments.

I have a nifty idea.  ^,^  Can you give me an example package where
build depends are different per platform, but the resultant package is
more or less the exact same (exact same feature set, exact same runtime
dependencies) ?  This hypothetical discussion is starting to loose focus
of real issues versus imaginary ones.  ;-)

> 
> > The "low
> > maintenance" of the packages results in "low flexibility" for the user,
> > since they can no longer "just install" an app, but then become
> > dependent on knowing things like which errata they have installed, which
> > distro they have (most Windows users aren't even sure which of 4
> > versions of Windows they have, as a point of how bad it is to make a
> > user know this stuff), etc.
> 
> You're exaggerating again, a lot.

You specifically said that packages are only intended to work on the
platform they are built for, and working on anything else is just dumb
luck.  That's no fun.

> 
> > Instead of fixing the problem, you're arguing about Fedora breaking the
> > packaging habits you've been forced to develop to hack around the
> > problem.
> 
> Huh? You you sure you don't confuse me with anyone else?

I don't think so - you're arguing for having Fedora avoid a perfectly
legitimate change of the release version solely for the sake package
dependencies, yes?

> 
> > > I give up here. Sorry. Going on with this "discussion" is wasted time
> > > as long as you don't propose a solution. A sentence like "*fix the
> > > problem*, don't fix the *hack* for the problem" is written quickly. It
> > > wipes away everything which has been commented on earlier.
> > 
> > Solution I've mentioned before - the applications are simply built one
> > way, the way that makes most sense for the user, and not on local build
> > location dependencies.  Let the package system deal with both runtime
> > and buildtime dependencies, don't just randmly apply patches or remove
> > features because the person building the package is too lazy to download
> > the dependency.  There's you fix, as I've said before.
> 
> Insufficient since the packager needs to adapt to the software, not
> vice versa. But as I've said, it is beyond my time to try to rephrase
> again and again in the hope that you'll understand my point of view.

yes, im feeling the same way.  aren't opinions fun?  you can never win. 
~,^

> 
> > > > 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.  ;-)
> > > 
> > > You fail to understand the implications of build requirements.
> > > 
> > 
> > Not sure what you mean here; a package has requirements, you install
> > them before building.  If you don't, it doesn't build.  Just like any
> > other piece of software.  What "implications" am I missing?  (seriously
> > - I don't enjoy being clueless if I can help it ;-)
> 
> _Optional_ features have _optional_ build dependencies. You can't
> depend on stuff that _is simply not available_. You can't install it
> because it's not available anywhere unless someone provides in in form
> of packages again. Now make the same unmodified src.rpm compile on

And what is the problem with getting the packages for the build
dependency?

> multiple platforms, where a different set of build requirements is
> available and possibly a different set of patches may need to be
> applied. This is the scenario of my initial comments.

Which if true is a serious problem, as I see it.  Different flavours of
Linux shouldn't need hugely different compilation options.  Grab the
stuff the package needs, build it, test it, done.  If something else is
needed based on something so silly as RH 8 vs RH 9 vs FC 1, something is
wrong somewhere.

> 
> > Perl/Python are co-installable with different versions, and thus are a
> > different issue.
> 
> Oh, great, a second Perl installation. As if Python/Python2 wouldn't
> be enough already.

If that's what it takes to make things work, then that's what it takes. 
I didn't say it was perfect, just that it solves the problem that users
shouldn't ever have to rebuild to software, and users shouldn't have to
run around figuring out what their system is to find the right package
and deal with that mess.  In a truly ideal world, Perl/Python/etc.
wouldn't keep breaking compatibility so often.  ~,^  Since that's *not*
reality, the only solution left for sane packages (form a user's point
of view again) is to let any necessary versions be installed so the
user's apps just work and the user doesn't even have to think about OS
versions or dependencies.

> 
> > Distros based on 2.96 were inherently broken anyhow,
> 
> http://www.redhat.com/advice/speaks_gcc.html

As a developer who had to, and even recently still had to, explain to
users why software didn't compile/work on RH7 (even tho it worked fine
with both gcc 2.95 and gcc 3.2), that explanation has and still does
fall very short.  Even now, it's a pain, because it still kills
intelligent packaging efforts for people who need to support those OS
releases.  Thank Red Hat.  ;-)

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