[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Kind request: fix your packages

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?

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

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.

> This hypothetical discussion is starting to loose focus
> of real issues versus imaginary ones.  ;-)

Wonder why? Not sure what I've been dragged into. :)

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

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

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

- -- 
Michael, who doesn't reply to top posts and complete quotes anymore.

Version: GnuPG v1.2.3 (GNU/Linux)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]