Toshio Kuratomi wrote:
Matthew Woehlke wrote:
Toshio Kuratomi wrote:
Uhm... you realize that building an rpm every time you want to test a
change as you develop an app is incredibly clunky? It really is not
going to happen. Really.
I still submit that this itself is a problem that should be worked on...
Why must it be "too clunky"? Why can't we fix it so that expecting
developers to install via rpm, even for incremental builds, is perfectly
reasonable?
Here's the workflow:
[snip]
Thanks, but I didn't need an analysis of the current problems. I know
it's not practical right now, but that was the whole point I was trying
to make! Here's what I'd like to see:
Current workflow:
svn up
make
make install
some-app
Proposed workflow:
svn up
make
rpm-dev-install .
some-app
See how painless that was? And now, rather than 'make install' littering
my drive with untracked files, the helper:
- rolled an incremental RPM
- updated the existing package
- ...which removed any old files no longer there
- ...and added/updated any modified files
- updated the rpm database to note that some-app is now installed (if it
wasn't)
- ...which also means that if some-app uses libfoo-devel, rpm now
knows this and won't remove libfoo-devel until I remove some-app
Of course this process probably won't involve going through
a full rpmbuild, just something that tracks the installed files in rpm's
database along with updating the database for dependencies (i.e. it
would replace 'make install' but not 'make all').
This is definitely not what rpm is designed to do.
You could probably write a script that did it but you'd have to hook it
up to all the dependency generating scripts and do minimal parsing of
the spec file to get manually specified deps and you'd still have to
work out how to do the make install step cleanly.... I don't see much
return on investment here but YMMV.
Yes, you'd probably need to write a spec file, and you might need to
fiddle with the 'make' step as well to make it more rpmbuild-like. Of
course, something like this could also be integrated with popular build
systems (I'd mainly care about cmake).
For that matter, rpmbuild might just work as-is if allowed to start with
"dirty" source and build trees; you'd have to set things up carefully,
but then it would be just a matter of having the source in a particular
spot (which could be symlinked to get around any inconveniences there)
and running rpmbuild instead of make. Then the trick is just making it
work as not-root.
What I *don't* get it what's so special about rpm generation that people
seem to think this can't be done. Would it produce an rpm that is
suitable according to Fedora's packaging guidelines? Of course not! But
that's not the objective. Yes, there are reasons current rpmbuild works
the way it does, and I don't think we should change that. I'm just after
a way to allow "non-canon" rpm's rolled from incremental builds.
Further, they should NOT be root-owned, they should be installable
without needing to be root*, and they should stick out like sore thumbs
if there is a conflict with repo packages (assuming they aren't
installed "in addition", i.e. in /usr/local).
(* There should be a way for root to flag a particular such package as
being allowed to satisfy dependencies for other packages, that would be
persistent across updates of the package. IOW, I can install qt-copy,
become root and tell rpm to use qt-copy to satisfy dependencies, and
then poppler-qt4 without having to install the repo qt4. Now, obviously,
trying to remove qt-copy will refuse due to poppler-qt4 needing it until
I use the magic incantation (e.g. '--force --nodeps' or something along
those lines, which would of course break poppler-qt4, but I was warned
;-) )... unless I do it as root, which would just remove poppler-qt4.)
All the RPM database needs to do is store a single lousy bit of
information per package. The "is a dep" flag. Presumably installing
packages directly with rpm would not set this flag.
s/not// to match the behaviour you say aptitude has.
Eh? I would think that 'rpm -Uvh <some-package>' should result in
<some-package> being flagged as a non-candidate-for-culling (unless rpm
is told otherwise). IOW, if I hand-installed some rpm, I don't want it
auto-culled. Maybe there is some miscommunication?
Possibly. I interpret the "is a dep flag" to mean package Foo was
installed as a dep of package Bar. Therefore, when package Foo is
uninstalled, packages that depend on Bar and have "is a dep" set would
be uninstalled.
Right, if those "is a dep" packages aren't needed by anything else (just
to clarify; I'm sure that's what you meant).
What I don't get: Callum said that "rpm -i blah.rpm" would mark "blah"
as a non-dep, i.e. would not be auto-culled. As I understand, you said
that it *would* mark it for auto-culling. It seems to me that the former
behavior is preferable; anything I install by hand should be
non-auto-culled unless I say otherwise, not the other way around.
--
Matthew
This message represents the official view of the voices in my head.
-- Unknown
(found at http://goldmark.org/jeff/stupid-disclaimers/fun.html)
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
