Kind request: fix your packages

[Sean Middleditch]

On Fri, 2003-10-03 at 18:09, Michael Schwendt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Fri, 03 Oct 2003 16:39:48 -0400, Sean Middleditch wrote:
> 
> > > 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? 
> 
> You do know what rpmfind.net and rpmseek.com are, don't you?

Somewhat - big links of packages, yes?  Good examples of sickeningly
horrible site/UI design, if nothing else.  ~,^

> 
> > 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) ?
> 
> No, because I've been referring to "different build deps and different
> feature set" all the time.

I'm guessing the feature set argument is pointless, then, since neither
of us agree which is more important.

> 
> Package examples for that [different] scenario could be Bluefish
> (aspell), Sylpheed (aspell, gpgme, gnupg), Apt as well as packages
> that depend on NPTL, openssl and packages which set a
> distribution-specific package release tag themselves. And let me
> repeat -- might be necessary ;) -- that detection of some build
> platform features can be performed without examining
> /etc/redhat-release, but can get ugly.

Right, which is the "fix the problem, not the hack" I've been mentioning
a lot - if it *is* so ugly, then *that* needs to be fixed.

> 
> > This hypothetical discussion is starting to loose focus
> > of real issues versus imaginary ones.  ;-)
> 
> Wonder why? Not sure what I've been dragged into. :)

:P

> 
> > 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.
> 
> Doesn't matter. Packages are created for a known set of distributions.
> You cannot make sure that a package compiles with older software and
> that it will still compile with newer software. Such configurations
> are unsupported.

I've never said otherwise.

> 
> > > > 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?
> 
> No. Point me to the message in the archives, please.

http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00061.html

Hmm, looks like I did get you confused with someone else there.  my
apologies.  ^^;

> 
> > > _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?
> 
> Lack of human resources to package the latest software for old
> distributions? Maybe even incompatibility due to insufficient compiler
> versions? Maybe conflicts with other components?

but the latest software shouldn't *need* repackaging for older
distributions, of course.

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