Kind request: fix your packages

Michael Schwendt ms-nospam-0306 at arcor.de
Fri Oct 3 17:52:45 UTC 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 03 Oct 2003 12:04:35 -0400, Sean Middleditch wrote:

> > > > It's the packager's (distributor's) responsibility to
> > > > provide a working set of dependencies. Those people, who send newbies
> > > > to rpmseek.com where the newbie chooses a prebuilt package for an
> > > > arbitrary distribution and fails to locate missing dependencies, are
> > > > nuts and are not helpful. It is much more helpful to point newbies to
> > > > repositories and tools like Synaptic.
> > > 
> > > The only reason its "nuts" is because packages are made with no thought
> > > of real users.  It shouldn't have to be nuts.  It should just up and
> > > work.
> > 
> > Impossible mission. An individual package will never know *where* to
> > get dependencies. It only knows *what* is missing. However, if the
> > user makes use of package tools, the problem is solved. Back to your
> > example, of a package requiring libfoo.so.23.4.6 (or similar), it will
> > be entertaining to make the newbie understand that the file is
> > provided by package libfoo-1.0 and not libfoo-0.9 or libfoo-2.0.
> 
> Nonsense, package networks already exist today.  I almost never manually
> download individual dependencies anymore.  Let the package network tool
> handle the dependency fetching.

Apparently, you need longer quotes in order to not kill the context
and misunderstand comments. Notice the comment on _package tools_
compared with picking individual packages at rpmseek.com/rpmfind.net.
You're creating endless loops in this discussion.

> > > I'm not sure how
> > > well RPM supports file over-rides, but some clever packaging could avoid
> > > the problem for users even when the app was designed by someone who
> > > enjoys watching users cry.  ;-)
> > 
> > Still, the app doesn't build if its build requirements aren't
> > satisfied. Another loop in the discussion.
> 
> So satisfy it.  The developer can fricken download the dependency. 
> Problem solved.  If the person building the package can't download the
> dependency, what in the nine hells is he doing building packages?  ;-)

*sigh* He isn't. It is _you_ who wants the src.rpms be much more
flexible than what we have presently. My arbitrary example -- and even
a very basic one -- with aspell and one src.rpm for multiple platforms
still holds true. The "real user" (adapting your terminology) works
with prebuilt binary packages and not src.rpms. Packagers aim at
creating high-quality binary packages for "real users" while at the
same time keeping the maintenance requirements low. Clean src.rpms are
an added thing and allow the average user to rebuild stuff from source
without big problems. Let the rare user with an exotic installation
and configuration adjust the src.rpm if need be.

> > > As you've noted, users can always install dependencies.  So can
> > > developers.  Developers are probably more capable of it.  So your
> > > package depends on something only in RH8+, but you want it to work in
> > > RH7 too?  Just depend on the devel files for the newer version.  People
> > > building on RH7 can grab it and build on in bliss, and you as a packager
> > > don't need to waste time making silly hacks.  ^,^
> > 
> > With current tools and implementation of explicit versioned build
> > requirements, that would cause the application to not build at all on
> > an unmodified RH7 unless the src.rpm examines in detail what's there
> > and what's not. Maybe we should go back to the early mails and restart
> > there. ;)
> 
> The problem needs to be fixed in RPM then, and not have Fedora let you
> continue hacking around the problem using etc/release.  Like I said the
> first around, *fix the problem*, don't fix the *hack* for the problem.

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.

Maybe we should pick a single topic (like automated detection of build
requirements) and beat that one to death. But the current discussion
touches too many topics at once and is fruitless. You won't get any
packagers to prepare src.rpms for unknown target platforms by
duplicating the work of "configure" scripts where a straight-forward
detection of available packages and package versions wouldn't suffice.
You would deal with things like detecting inter-library dependencies,
compiler features/bugs, linker tests, and things like that.

> Again, optional fetures should *never* be compile time.  That's
> horrible, broken design, and any app doing that has no business being
> ona  user's desktop to begin with.  Compile the app will all features
> turned on,

Usually, this requires build dependencies to be available beforehand and
fails where optional build dependencies are unavailable, and e.g. a
plug-in cannot be built. I've seen Michael K. Johnson's comment on
run-time configuration as opposed to compile-time configuration, but
that refers to something else. In order to build an optional run-time
configurable part of an app, you need to build it from source code at
some point im time. This requires build dependencies to be available.

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


["official" RPM packaging policy ]

> Other things can be glossed over to a degree.  Compiler version really
> (mostly) only affected C++ stuff, and that's history now.

No one still using GCC 2.95.x or GCC 2.96 or early GCC 3 release and
needs patches? What about glibc, Perl, Python? Also, do SuSE still use
RPM 3.x? ;) 

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/fbdt0iMVcrivHFQRAri9AJwPF+Iy1S3tlnvfriSAv8aceUY3uQCggQz5
kw5PZq7Xb41MohP/IsvekmI=
=gEMR
-----END PGP SIGNATURE-----





More information about the fedora-devel-list mailing list