Russ Allbery: > Patrick Schleizer <[email protected]> writes: > >> I am upstream as well as would like to become a debian maintainer some >> day. Still learning packaging. > >> Due to the luxury of being upstream as well, the upstream source package >> can be formatted in any way I wish. [In this case it is a simple package >> with shell scripts only.] > >> Personally I find it useful to have a folder layout like this: >> upstream_source_folder/usr/bin/some_script >> upstream_source_folder/usr/bin/another_script >> upstream_source_folder/etc/some_config >> upstream_source_folder/etc/init.d/some_init > >> Those should get installed to /usr/bin/some_script etc. > >> Is it possible to simplify packaging? I mean, is it possible to automate >> this without using a package.install file? In other words, is it >> possible to tell debhelper, "use the >> upstream_source_folder/usr/bin/some_script and install it to >> /usr/bin/some_script"? > > For all of the Stanford-internal packages that we make that are just > collections of scripts like that, we use the following rune in > debian/rules: > > override_dh_auto_install: > rsync -C --recursive --links --perms --times --delete \ > --exclude debian --exclude t --exclude .gitignore \ > $(CURDIR)/ debian/$(PACKAGE) > > and then just make the internal layout of the package match the installed > layout. (Obviously you need a build dependency on rsync.) This provides > zero assistance to people using your package not inside Debian, so you may > not want to do things this way and instead provide some sort of Makefile > to install things, but it works great for quick internal packages.
Would a package created that way be allowed to enter Debian (if there are no other issues)? Is any of these Stanford-internal packages available to be looked at in a public place? -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
