Kind request: fix your packages

[Michael Schwendt]

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

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

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

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

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

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

> Distros based on 2.96 were inherently broken anyhow,

http://www.redhat.com/advice/speaks_gcc.html


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