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: cvs co web-app cd web-app vim web-app.cfg ./start-web-app [hit web app in browser to make sure it runs] ^C vim web-app/do-something.py vim web-app/templates/do-something-page.html ./start-web-app [hit web-app in browser and find there's a problem] ^C vim TODO [write note to fix this as you've got to get some sleep, go to work, walk the dog, make dinner, kiss your wife, yum update, yum erase openoffice, yum install nethack, play nethack, go to sleep, get up and....] cat TODO vim web-app/do-something.py ./start-web-app [hit web-app in browser and find there's a problem] [wash rinse repeat] Now here's the same workflow with rpm building in there:: cvs co web-app cd web-app vim web-app.cfg python setup.py sdist mv dist/web-app-0.0.tar.gz .. cd .. rpmbuild -ba web-app.spec sudo rpm -Uvh web-app-0.0-0.noarch.rpm sudo /etc/init.d/web-app start [hit web app in browser to make sure it runs] cd web-app vim web-app/do-something.py vim web-app/templates/do-something-page.html python setup.py sdist mv dist/web-app-0.0.tar.gz .. cd .. vim web-app.spec rpmbuild -ba web-app.spec sudo rpm -e web-app sudo rpm -Uvh web-app-0.0-1.noarch.rpm sudo /etc/init.d/web-app start [hit web-app in browser and find there's a problem] ^C vim TODO [write note to fix this as you've got to get some sleep, go to work, walk the dog, make dinner, kiss your wife, yum update, yum erase openoffice, yum install nethack, play nethack, go to sleep, get up and....] cat TODO cd web-app vim web-app/do-something.py python setup.py sdist mv dist/web-app-0.0.tar.gz .. cd .. vim web-app.spec rpmbuild -ba web-app.spec sudo rpm -e web-app sudo rpm -Uvh web-app-0.0-1.noarch.rpm sudo /etc/init.d/web-app start [hit web-app in browser and find there's a problem] [wash rinse repeat] > 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. >>>> That could mean rpm (since rpm is >>>> responsible for taking the package and turning it into files on the >>>> filesystem) or that could mean yum since yum is the one that actually >>>> knows whether a package is being installed due to depsolving or user >>>> request. Doing this at a higher level means that information gets lost >>>> (for instance, if you do this in PackageKit, there won't be any >>>> information about what anaconda chose to install due to chckboxes being >>>> clicked and which things were installed due to dependencies). >>> 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. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
