Kind request: fix your packages

Fri Oct 3 18:28:42 UTC 2003

On Fri, 2003-10-03 at 13:52, Michael Schwendt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Fri, 03 Oct 2003 12:04:35 -0400, Sean Middleditch wrote:

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

This happens, yes - my apologies.  My memory tends not to go back
further than about 30 seconds.  ~,^  Psychologists would call it
goldfish syndrome if they knew about me.  ;-)

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.

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

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

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.

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

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.  If it is too
hard to do this, then this maybe needs to move to the RPM list, instead
of just saying "oh well" and continuing to screw over the users.

I've packaged for Debian before, but never an RPM distro - if it really
is so much harder to do with spec files what is dead simple in a dpkg,
then RPM needs work ("the problem"), versus ignoring it and using
/etc/release to avoid use of real dependencies ("the hack").

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

This I agree on.  Sorry for my rambling nature.  ^^;

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

Correct; which again needs to be brought up on the RPM list, not
complaining abou tit on the fedora list.  ~,^

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

For a user-oriented app, enabling or disabling a feature is
configuration.  Different terms, exact same end-result tho.

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

Which anyone building the RPMs are free to install if they want to build
it, of course.

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

> 
> ["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? ;) 

Legacy cruft isn't really a part of Fedora's goals, so I don't see
Fedora bending over backwards to support it.  ;-)  And, since there
really isn't any kind of standard yet, we can gloss over legacy since it
never claimed to be a part of the standard.  ^,^

I'd say its perfectly acceptable to state that packages only work on
"RPM Policy 1.0 compliant operating systems"; packages for legacy
systems, which will fade out soon enough (speaking in computer time
anyways) will still be a pain, but what is one to do?  Moving forward
sucks sometimes, but it's sure as hell better than never progressing. 
:P

Perl/Python are co-installable with different versions, and thus are a
different issue.  Distros based on 2.96 were inherently broken anyhow,
and 2.95 is history.

In any event, this is off on a tangent from the original discussion. 
;-)  I'll have to bring this up somewhere more relevant.  ^,^

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