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(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list --
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.