MESSAGE
| DATE | 2015-11-20 |
| FROM | Chris Knadle
|
| SUBJECT | Re: [Hangout-NYLXS] permissions in Debian packages?
|
prmarino1-at-gmail.com:
> Chris Yea I've seen that method too. its still messy because it assumes
> you are compiling as root or have unlimited sudo on chown and or chmod
> permission.
Debian packages get built as root (usually via 'fakeroot' which is typically
how it's done with build chroots and buildd setups), and so the debian/rules
file during the build as well as [pre|post]init files during package
installation also run as root. Therefore debian/rules and [pre|post]init
has access to chown, chmod, etc. It's somewhat unfortunate but you can also
quickly see why that is.
> It strikes me as very odd that they didn't adopt something similar to the
> files section of an RPM spec file by now, because I see a massive
> potential for package permissions/ownership clashes between packages
> without it.
Debian packages have several "styles" that are available for how they're put
together. Usually you can tell which style a package uses by examining
debian/source/format and the debian/rules file. The main styles are:
- dh with overrides ("automatic debhelper" method -- most popular)
- debhelper with individual dh_ calls (2nd most popular, < 30% pkgs)
- CDBS (3rd, < 20% pkgs)
- "manually" built packages (rare, but needed for particular cases)
The debian/rules file is a Makefile, so in general you can do anything in it
that you could do in a Makefile -- which is a lot. If the package uses
debhelper (including 'dh') then debhelper automatically looks for files
named debian/.install or .files
for what particular files should go with each of the binary packages being
assembled -- these are file lists that the maintainer creates for what files
go with what binary package. Have a look at 'man dh_install'.
Likewise you can make .docs, .manpages, .links -- a
whole slew of these things. In each case these files are associated with a
particular debhelper script, so for instance the .manpages file is mentioned
in the "FILES" section of 'man dh_installman'.
There are a lot of these dehelper scripts... so in many cases the file
permissions are handled automatically, but there are always exceptions where
you need to do something slightly different. There's also a dh_fixperms
script that typically gets called, but I don't see maintainer-made files
that are associated with it.
I had a quick look at some documentation concerning the %files section of an
RPM spec file (as I'm not in the habit of building RPMs):
http://www.rpm.org/max-rpm/s1-rpm-build-creating-spec-file.html
and didn't find anything mentioning setting file permissions. It looks like
that's done via %defattr from what (little) I can tell:
https://stackoverflow.com/questions/6952384/what-the-defattr-means-in-rpm-spec-files
> Then again since RPM switched from open source to GPL along time ago I
> find it odd Debian didn't adopt it, but as us Perl programmers
> (differentiated from Perl scripters by the fact that we understand how
> references work and why they exist) put it there are many ways to do It.
>
> I will say this it is a lot simpler when you get down to it than RPMS or
> ebuilds (Gentoo/Portage), but simplicity for the sake of simplicity isn't
> always your friend. :)
Yes.
Conceptually Debian packaging is simple, but... typically the packaging
usually isn't. Most of the time Debian packaging is fun and useful work,
but it's also common to run into something new that's a little more
complicated than what one has seen before. I'll point out a few things I've
run into lately.
- I recently updated the libssh package (not used by openssh) for myself
which had some .symbols files that documented which upstream version # the
various subroutines were added in, and the build would fail if these weren't
updated for the change in the ABI. A quick web search came up with this
which explains this:
https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#librarysymbols
- I have a package I work on where I need to break out one of the binary
packages into a Multiarch package to allow installing that binary package
from a different architecture. Have a look at the spec -- I bet your eyes
glaze over a few times.
https://wiki.ubuntu.com/MultiarchSpec
- And then there's systemd. Boy oh boy what a joy /that/ is
packaging-wise. Grr! You know those files in /etc/default/ for
settings and to disable starting a daemon by default? Well, systemd can't
handle that by itself:
https://wiki.ubuntu.com/SystemdForUpstartUsers#A.2BAC8-etc.2BAC8-default_files_which_enable.2BAC8-disable_jobs
The "ExecStartPre=" thing the page mentions means starting a /shell script/
to check the variable, returning failure if the setting is "disabled", after
which systemd considers the service to be in a "failed" state.
Debian Policy still requires that sysvinit scripts be shipped with a
package, even though systemd is the default "init system". This is a good
thing because it means the other traditional init systems will continue to
work... but it leads to confusion where if the maintainer ships a systemd
service file it means it'll have to be able to co-exist alongside the
traditional init system file, leading to several types of confusion.
- Then there's the fun that systemd won't wait until the network is fully up
before it starts daemons (in parallel with everything else at once):
https://wiki.freedesktop.org/www/Software/systemd/NetworkTarget/
and that gets into another whole /class/ of bugs. Same thing with upstart.
-- Chris
--
Chris Knadle
Chris.Knadle-at-coredump.us
_______________________________________________
hangout mailing list
hangout-at-nylxs.com
http://www.nylxs.com/
|
|
