Bug#910707: Bug#908796: udev (with sysvinit) fails to find devices at boot

[Felipe Sateler]

(Dropping original bug, adding cloned bug, full quote for context)

On Wed, Oct 10, 2018 at 4:38 AM Guillem Jover  wrote:

> Hi!
>
> On Tue, 2018-10-09 at 22:01:21 -0300, Felipe Sateler wrote:
> > Control: clone -1 -2
> > Control: retitle -2 start-stop-daemon: please implement service
> readiness protocol
> > Control: severity -2 wishlist
>
> > On Sun, Sep 30, 2018 at 8:15 PM Michael Biebl  wrote:
> > > The only supported way in udev to signal readiness is the sd-notify
> API.
> > > My gut feeling is, that having an sd-notify wrapper for non-systemd
> > > systems (e.g. directly built into start-stop-daemon via say an
> > > --wait-for-sd-notify switch) would be the cleanest and most robust way.
> > > This might even benefit other daemons besides udevd.
> >
> > Indeed, it seems to me that start-stop-daemon supporting the same service
> > readiness protocol systemd implements[1] would make things easier for
> udev
> > and other services.
> >
> > Short description for those not familiar: the service manager (or ssd in
> > this case) sets up a AF_UNIX socket, and passes on the address to the
> > daemon via the NOTIFY_SOCKET environment variable. When the daemon sends
> a
> > message containing READY=1, then ssd should consider the service up and
> it
> > can exit. More details at the linked manpage.
>
> Hah, this is already almost implemented. Was planning on finishing the
> couple of XXX (including setting the envvar) and docs, testing and
> merging it for 1.19.3 or so (targeted at 1w or 2w from now). :)
>
>   <
> https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=pu/s-s-d-notify
> >
>


Awesome. This should help a lot.

-- 

Saludos,
Felipe Sateler

Re: Bug#908796: udev (with sysvinit) fails to find devices at boot

[Felipe Sateler]

(Dropping original bug, adding cloned bug, full quote for context)

On Wed, Oct 10, 2018 at 4:38 AM Guillem Jover  wrote:

> Hi!
>
> On Tue, 2018-10-09 at 22:01:21 -0300, Felipe Sateler wrote:
> > Control: clone -1 -2
> > Control: retitle -2 start-stop-daemon: please implement service
> readiness protocol
> > Control: severity -2 wishlist
>
> > On Sun, Sep 30, 2018 at 8:15 PM Michael Biebl  wrote:
> > > The only supported way in udev to signal readiness is the sd-notify
> API.
> > > My gut feeling is, that having an sd-notify wrapper for non-systemd
> > > systems (e.g. directly built into start-stop-daemon via say an
> > > --wait-for-sd-notify switch) would be the cleanest and most robust way.
> > > This might even benefit other daemons besides udevd.
> >
> > Indeed, it seems to me that start-stop-daemon supporting the same service
> > readiness protocol systemd implements[1] would make things easier for
> udev
> > and other services.
> >
> > Short description for those not familiar: the service manager (or ssd in
> > this case) sets up a AF_UNIX socket, and passes on the address to the
> > daemon via the NOTIFY_SOCKET environment variable. When the daemon sends
> a
> > message containing READY=1, then ssd should consider the service up and
> it
> > can exit. More details at the linked manpage.
>
> Hah, this is already almost implemented. Was planning on finishing the
> couple of XXX (including setting the envvar) and docs, testing and
> merging it for 1.19.3 or so (targeted at 1w or 2w from now). :)
>
>   <
> https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=pu/s-s-d-notify
> >
>


Awesome. This should help a lot.

-- 

Saludos,
Felipe Sateler

Re: Bug#908796: udev (with sysvinit) fails to find devices at boot

[Felipe Sateler]

Control: clone -1 -2
Control: retitle -2 start-stop-daemon: please implement service readiness
protocol
Control: severity -2 wishlist



On Sun, Sep 30, 2018 at 8:15 PM Michael Biebl  wrote:

>
> The only supported way in udev to signal readiness is the sd-notify API.
> My gut feeling is, that having an sd-notify wrapper for non-systemd
> systems (e.g. directly built into start-stop-daemon via say an
> --wait-for-sd-notify switch) would be the cleanest and most robust way.
> This might even benefit other daemons besides udevd.
>

Indeed, it seems to me that start-stop-daemon supporting the same service
readiness protocol systemd implements[1] would make things easier for udev
and other services.

Short description for those not familiar: the service manager (or ssd in
this case) sets up a AF_UNIX socket, and passes on the address to the
daemon via the NOTIFY_SOCKET environment variable. When the daemon sends a
message containing READY=1, then ssd should consider the service up and it
can exit. More details at the linked manpage.

[1] https://manpages.debian.org/stretch/libsystemd-dev/sd_notify.3.en.html
-- 

Saludos,
Felipe Sateler

Bug#843073: dpkg: dpkg-shlibdeps failing due to /usr/lib/ld-linux-armhf.so.3 symlink

[Felipe Sateler]

On 15 November 2016 at 18:17, Wookey <woo...@wookware.org> wrote:
> On 2016-11-15 15:53 -0300, Felipe Sateler wrote:
>> On Tue, 15 Nov 2016 17:22:12 + Wookey <woo...@wookware.org> wrote:
>> > Package: dpkg
>> > Version: 1.18.10
>> > Severity: normal
>> >
>> > I built a large package (mythtv) with this recipie:
>> > git clone https://github.com/MythTV/packaging -b fixes/0.28
>> > cd packaging/deb
>> > ./build-debs.sh fixes/0.28
>> >
>> > This all works fine until the dh_shlibdeps when packing it up at the
>> > end.
>> >
>> > which complains about missing dependency info for
>> > /usr/lib/ld-linux-armhf.so.3
>>
>> This is the same as #843073, so merging. Raphael has proposed a patch
>> on that bug, but it needs more testing before it is accepted.
>
> Right. Cheers for that. (I failed to check the dpkg bugs first because
> I started filing against glibc and checked that list, then realised
> part way through that this was best filed against dpkg).
>
> How is the usrmerge done? bind-mounting? hardlinks?

Softlinks. /bin => usr/bin, /sbin => usr/sbin , /lib => usr/lib,
/lib${multilib} => usr/lib/lib${multilib} .

> Is dpkg-shlibdeps the only thing that is going to wrong if files stop
> having a canonical location in the system? It's a pretty major change
> having every library (and a load of binaries?) appear twice? (Or do I
> misunderstand how this is implemented?).

Guillem pointed out on IRC that dpkg-query --search will also be confused.
For most things it shouldn't matter, as things will be where people expect
them. Some other programs are bound to be confused. systemd-delta, for
example, was also confused, but it was fixed already. To my knowledge,
dpkg-query --search and dlocate are the only ones (in fact, the problem in
dpkg-shlibdeps is because it uses dpkg-query --search).

> Like Guillem, I'd be a lot happier if files, especially libraries,
> only existed in the place they existed, and if we want to move that
> then we should move it in the packaging.

That would be great from my POV. However, it has some drawbacks: Stuff in
/bin cannot be moved to /usr/bin until /bin is a link to /usr/bin (ditto
sbin). Otherwise, for example fsck won't find the /sbin/fsck.$fs programs.
In general, way too many things hardcode paths in /bin or /sbin. So the
options are a period where package metadata does not match the filesystem,
or we have a long period of uninstallability until all packages + usrmerge
are installed.

> Isn't there potential for
> autoconf or libtool to get confused too?

Yes, there is some potential for confusion. If you program detects the path
of binaries or libraries and then hardcodes that, it may get paths wrong,
as it will probably choose the / path over the /usr one. This won't be a
problem for usrmerged systems, but it will for non-merged ones.

> Anyway, I'll test raphael's patch.

Thanks!

-- 

Saludos,
Felipe Sateler

Bug#843073: dpkg: dpkg-shlibdeps failing due to /usr/lib/ld-linux-armhf.so.3 symlink

[Felipe Sateler]

Control: forcemerge 843073 844430

Hi,

On Tue, 15 Nov 2016 17:22:12 + Wookey <woo...@wookware.org> wrote:
> Package: dpkg
> Version: 1.18.10
> Severity: normal
>
> I built a large package (mythtv) with this recipie:
>  git clone https://github.com/MythTV/packaging -b fixes/0.28
>  cd packaging/deb
>  ./build-debs.sh fixes/0.28
>
> This all works fine until the dh_shlibdeps when packing it up at the
> end.
>
> which complains about missing dependency info for
> /usr/lib/ld-linux-armhf.so.3

This is the same as #843073, so merging. Raphael has proposed a patch
on that bug, but it needs more testing before it is accepted.


Saludos,
Felipe Sateler

Bug#843073: More information

[Felipe Sateler]

Hi,

The problem seems to occur in the Shlibs perl module[1]. In
particular, the function find_library looks in a list of configured
paths. But for each path, it checks if the path is a link to another
known path, and if so, it does not use the original link but the
resolved path. Thus for /lib, it detects that it is a link to
/usr/lib and uses the latter instead. Complicating things:

1. Many libraries live in /usr/lib/$triplet, but /lib/$triplet is not
a link to the latter. Thus this link resolving is not done.
2. On at least my (usrmerged) amd64 machine, /usr/lib64 is not a
symlink to /usr/lib, and ld-linux-86_64 lives there instead of
/usr/lib.

It's unclear what the best solution for this is. The indirection is
there due to bug #453885. Maybe find_library should be changed to
return a list of possible matches, and have dpkg-shlibdeps decide
which one to use by using the first one for which dpkg-query returns a
positive result. That would be an API break on libdpkg-perl though.

[1] 
https://sources.debian.net/src/dpkg/1.18.13/scripts/Dpkg/Shlibs.pm/#L161-L166

-- 

Saludos,
Felipe Sateler

Bug#836211: dpkg: Cannot upgrade some packages on overlayfs: Invalid cross-device link

[Felipe Sateler]

On 1 Sep 2016 3:59 a.m., "Johannes Schauer" <jo...@debian.org> wrote:
>
> Hi,
>
> On Wed, 31 Aug 2016 12:16:10 -0300 Felipe Sateler <fsate...@debian.org>
wrote:
> > overlayfs does not support renaming directories when the directories
> > live in the lower filesystem:
> >
> >  * Directory renames only allowed on "pure upper" (already created on
> >  * upper filesystem, never copied up).  Directories which are on lower
or
> >  * are merged may not be renamed.  For these -EXDEV is returned and
> >  * userspace has to deal with it.  This means, when copying up a
> >  * directory we can rely on it and ancestors being stable.
> >
> >
https://github.com/torvalds/linux/blob/v4.8-rc2/fs/overlayfs/copy_up.c#L318-L322
> >
> > Unfortunately this means that dpkg fails at least in the case where a
> > directory is converted into a file: apt 1.3~rc2 moves
> > /usr/share/bug/apt/script to /usr/share/bug/apt . This causes dpkg to
> > fail when running in an overlayfs with the following error:
> >
> > # dpkg -i /var/cache/apt/archives/apt_1.3~rc3_amd64.deb
> > (Reading database ... 11401 files and directories currently installed.)
> > Preparing to unpack .../archives/apt_1.3~rc3_amd64.deb ...
> > Unpacking apt (1.3~rc3) over (1.3~rc2) ...
> > dpkg: error processing archive
> > /var/cache/apt/archives/apt_1.3~rc3_amd64.deb (--install):
> >  unable to move aside './usr/share/bug/apt' to install new version:
Invalid cross-device link
> > dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
> > Processing triggers for libc-bin (2.23-5) ...
> > Errors were encountered while processing:
> >  /var/cache/apt/archives/apt_1.3~rc3_amd64.deb
> >
> > I don't know what the correct workaround should be.
> >
> > This can break pre-build upgrades in sbuild when the schroot is of
> > overlayfs type.
>
> thanks for the analysis!
>
> I just stumbled across the exact same problem with sbuild in a directory
type
> overlayfs schroot. My workaround: destroy the chroot (you can now use
> sbuild-destroychroot) and then recreate it with sbuild-createchroot. :(

You can also enter the source chroot and upgrade there, as that skips the
overlayfs setup. I used  sbuild-update and it worked OK.

I discussed this with Guillem on IRC and he doesn't think adding
workarounds for this is reasonable, and this should be fixed in overlayfs.
Assuming a directory lives in the same device as itself seems reasonable to
me, and overlayfs should try hard to pretend it does.

Saludos

Bug#836211: dpkg: Cannot upgrade some packages on overlayfs: Invalid cross-device link

[Felipe Sateler]

Package: dpkg
Version: 1.18.10
Severity: normal

Hi,

overlayfs does not support renaming directories when the directories
live in the lower filesystem:

 * Directory renames only allowed on "pure upper" (already created on
 * upper filesystem, never copied up).  Directories which are on lower or
 * are merged may not be renamed.  For these -EXDEV is returned and
 * userspace has to deal with it.  This means, when copying up a
 * directory we can rely on it and ancestors being stable.

https://github.com/torvalds/linux/blob/v4.8-rc2/fs/overlayfs/copy_up.c#L318-L322

Unfortunately this means that dpkg fails at least in the case where a
directory is converted into a file: apt 1.3~rc2 moves
/usr/share/bug/apt/script to /usr/share/bug/apt . This causes dpkg to
fail when running in an overlayfs with the following error:

# dpkg -i /var/cache/apt/archives/apt_1.3~rc3_amd64.deb 
(Reading database ... 11401 files and directories currently installed.)
Preparing to unpack .../archives/apt_1.3~rc3_amd64.deb ...
Unpacking apt (1.3~rc3) over (1.3~rc2) ...
dpkg: error processing archive
/var/cache/apt/archives/apt_1.3~rc3_amd64.deb (--install):
 unable to move aside './usr/share/bug/apt' to install new version: Invalid 
cross-device link
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Processing triggers for libc-bin (2.23-5) ...
Errors were encountered while processing:
 /var/cache/apt/archives/apt_1.3~rc3_amd64.deb

I don't know what the correct workaround should be.

This can break pre-build upgrades in sbuild when the schroot is of
overlayfs type.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-8
ii  libc62.23-5
ii  liblzma5 5.1.1alpha+20120614-2.1
ii  libselinux1  2.5-3
ii  tar  1.29b-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  1.3~rc3

-- no debconf information

Bug#824515: /usr/bin/dpkg-query: ${db:Status-Abbrev} includes trailing space

[Felipe Sateler]

On 16 May 2016 at 20:23, Guillem Jover <guil...@debian.org> wrote:
> Hi!
>
> On Mon, 2016-05-16 at 20:01:13 -0400, Felipe Sateler wrote:
>> Package: dpkg
>> Version: 1.18.7
>> Severity: minor
>> File: /usr/bin/dpkg-query
>
>> The dpkg-query manpage says:
>>
>> > It contains the abbreviated package status, such as “ii” (since dpkg 
>> > 1.16.2).
>>
>> That turns out to be misleading, since the actual variable contains a
>> trailing space:
>>
>> $ dpkg-query --showformat='${db:Status-Abbrev}${Package}\n' --show dpkg 
>> anjuta
>> un anjuta
>> ii dpkg
>
> Actually, the behavior is correct, what might be misleading is the
> documentation. The abbreviated status contains three characters, one
> for the desired action, one of the package status and one for the
> error flag, which should usually be empty. Otherwise it would be ‘R’.
>
> I'll update the documentation to make that more clear.

Ah, that would be great indeed. I had no idea there was an error flag.
I suppose others don't either.

>
>> I think by now removing the space would be an API breakage (although
>> apparently nobody is using this[1]), so I think the thing to do now is
>> to fix the man page.
>
> Right, but not because the behavior is wrong. :)

:)


-- 

Saludos,
Felipe Sateler

Bug#824515: /usr/bin/dpkg-query: ${db:Status-Abbrev} includes trailing space

[Felipe Sateler]

Package: dpkg
Version: 1.18.7
Severity: minor
File: /usr/bin/dpkg-query

The dpkg-query manpage says:

> It contains the abbreviated package status, such as “ii” (since dpkg 1.16.2).

That turns out to be misleading, since the actual variable contains a
trailing space:

$ dpkg-query --showformat='${db:Status-Abbrev}${Package}\n' --show dpkg anjuta
un anjuta
ii dpkg

I think by now removing the space would be an API breakage (although
apparently nobody is using this[1]), so I think the thing to do now is
to fix the man page.

[1] https://codesearch.debian.net/results/status-abbrev/page_0

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-8
ii  libc62.22-7
ii  liblzma5 5.1.1alpha+20120614-2.1
ii  libselinux1  2.5-2
ii  tar  1.28-2.2
ii  zlib1g   1:1.2.8.dfsg-2+b1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  1.2.12

-- no debconf information

Bug#595112: /usr/bin/dpkg-maintscript-helper: Please provide helper for moving a conffile between packages

[Felipe Sateler]

On 11 October 2015 at 13:45, Felipe Sateler <fsate...@gmail.com> wrote:
> Please implement this helper in dpkg-maintscript-helper;

Please find attached a patch to kickstart the discussion.
Documentation is missing. accept_conffile will move a .dpkg-bak file
left from rm_conffile if upgrading from a version older than the
passed version (or only on first install if empy is passed as
version).

-- 

Saludos,
Felipe Sateler
diff --git a/scripts/dpkg-maintscript-helper.sh 
b/scripts/dpkg-maintscript-helper.sh
index 176920e..438d527 100755
--- a/scripts/dpkg-maintscript-helper.sh
+++ b/scripts/dpkg-maintscript-helper.sh
@@ -229,6 +229,64 @@ abort_mv_conffile() {
 }
 
 ##
+## Functions to accept a conffile removed with rm_conffile in another package
+##
+accept_conffile() {
+   local CONFFILE="$1"
+   local LASTVERSION="$2"
+   local PACKAGE="$3"
+   if [ "$LASTVERSION" = "--" ]; then
+   LASTVERSION=""
+   
PACKAGE="$DPKG_MAINTSCRIPT_PACKAGE${DPKG_MAINTSCRIPT_ARCH:+:$DPKG_MAINTSCRIPT_ARCH}"
+   fi
+   if [ "$PACKAGE" = "--" -o -z "$PACKAGE" ]; then
+   
PACKAGE="$DPKG_MAINTSCRIPT_PACKAGE${DPKG_MAINTSCRIPT_ARCH:+:$DPKG_MAINTSCRIPT_ARCH}"
+   fi
+   # Skip remaining parameters up to --
+   while [ "$1" != "--" -a $# -gt 0 ]; do shift; done
+   [ $# -gt 0 ] || badusage "missing arguments after --"
+   shift
+
+   [ -n "$PACKAGE" ] || error "couldn't identify the package"
+   [ -n "$1" ] || error "maintainer script parameters are missing"
+   [ -n "$DPKG_MAINTSCRIPT_NAME" ] || \
+   error "environment variable DPKG_MAINTSCRIPT_NAME is required"
+
+   debug "Executing $0 mv_conffile in $DPKG_MAINTSCRIPT_NAME" \
+ "of $DPKG_MAINTSCRIPT_PACKAGE"
+   debug "CONFFILE=$CONFFILE PACKAGE=$PACKAGE" \
+ "LASTVERSION=$LASTVERSION ACTION=$1 PARAM=$2"
+   case "$DPKG_MAINTSCRIPT_NAME" in
+   postinst)
+   if [ "$1" = "configure" ] &&
+  dpkg --compare-versions -- "$2" le-nl "$LASTVERSION"; then
+   finish_accept_conffile "$CONFFILE" "$PACKAGE"
+   fi
+   ;;
+   *)
+   debug "$0 accept_conffile not required in 
$DPKG_MAINTSCRIPT_NAME"
+   ;;
+   esac
+}
+
+
+finish_accept_conffile() {
+   local CONFFILE="$1"
+   local PACKAGE="$2"
+
+   if [ -e "$CONFFILE.dpkg-bak" ]; then
+   local md5sum="$(md5sum $CONFFILE | sed -e 's/ .*//')"
+   local old_md5sum="$(dpkg-query -W -f='${Conffiles}' $PACKAGE | \
+   sed -n -e "\' $CONFFILE ' { s/obsolete$//; s/.* //; p 
}")"
+   # Only move if target file has not been modified yet
+   if [ "$md5sum" = "$old_md5sum" ] ; then
+   mv -f "$CONFFILE.dpkg-bak" "$CONFFILE"
+   fi
+   fi
+}
+
+
+##
 ## Functions to replace a symlink with a directory
 ##
 symlink_to_dir() {
@@ -531,6 +589,9 @@ Commands:
   dir_to_symlink   [ []]
Replace a directory with a symlink. Must be called in preinst,
postinst and postrm.
+  accept_conffile  [ []]
+   Accept changes from a conffile that was removed in anothe package.
+   Must be called in postinst.
   help
Display this usage information.
 END
@@ -555,7 +616,7 @@ shift
 case "$command" in
 supports)
case "$1" in
-   rm_conffile|mv_conffile|symlink_to_dir|dir_to_symlink)
+   rm_conffile|mv_conffile|symlink_to_dir|dir_to_symlink|accept_conffile)
code=0
;;
*)
@@ -575,6 +636,9 @@ supports)
 rm_conffile)
rm_conffile "$@"
;;
+accept_conffile)
+   accept_conffile "$@"
+   ;;
 mv_conffile)
mv_conffile "$@"
;;

Re: [Pkg-zsh-devel] Bug#768079: zsh: fails to configure if /bin is a symlink to /usr/bin

[Felipe Sateler]

On 27 December 2015 at 13:11, Axel Beckert <a...@debian.org> wrote:
> Hi,
>
> Sven Joachim wrote:
>> On a system with everything in /usr[1,2], i.e. /bin is a symlink to
>> /usr/bin, zsh fails to configure:
>>
>> ,
>> | Setting up zsh (5.0.7-3) ...
>> | update-alternatives: using /bin/zsh5 to provide /bin/zsh (zsh) in auto mode
>> | update-alternatives: error: unable to install `/usr/bin/zsh.dpkg-tmp' as 
>> `/usr/bin/zsh': No such file or directory
>> | dpkg: error processing package zsh (--configure):
>> |  subprocess installed post-installation script returned error exit status 2
>> | Errors were encountered while processing:
>> |  zsh
>> `
>>
>> I guess update-alternatives does not like the fact that the /bin/zsh
>> alternative and its slave /usr/bin/zsh are at the same place.
>
> Reading this comment and https://bugs.debian.org/807185, I wonder if
> this is not something, that update-alternatives should generally fix
> in its --slave handling instead of each affected package individually.

Checking wether a slave link is the same as the master link because of
usrmerge sounds a bit too specific to me to add to a low-level tool
like update-alternatives. It's like asking `ln -s file file` to do
nothing instead of returning an error.

If there is a bug here in u-a, it is that the error message is not very helpful.


-- 

Saludos,
Felipe Sateler

Bug#804939: dpkg: DPKG_MAINTSCRIPT_PACKAGE_REFCOUNT meaning is not intuitive, very hard to use

[Felipe Sateler]

Package: dpkg
Version: 1.18.3
Severity: normal

Hi,

On a couple pam modules[1] we see the following pattern:

if [ "$1" = remove ] && [ "${DPKG_MAINTSCRIPT_PACKAGE_REFCOUNT:-1}" = 1];
then
: remove stuff
fi

However, this idiom is incorrect. Because REFCOUNT tracks the number of
packages that are above 'not-installed', it will include packages that
are removed but not purged. If the package in question has any conffiles
or a postrm, then the above block may never be executed. The semantics
of this variable make it impossible to answer when a dpkg-tracked (ie,
not a conffile) file is removed (eg, there is no copy of a multiarch
library installed).

I propose that a new variable is introduced, that tracks the number of
packages that are above 'config-files' (or maybe, at or above
'unpacked'). The idea is to more closely match the idea of "the number
of packages that are installed". A package that is removed, but not
purged, should not be considered in the refcount.


At the very least, this very weird semantics need to be better
explained in the manpage. It should explicitly mention removed but not
purged packages, and it should clarify what is the value when 
`postrm purge` is invoked (this should also apply to my propsed
variable).

I note that of the 6 usages in the archive, only 2 are correct. I almost
introduced 3 more incorrect ones (but luckily those packages already had
postinst, so the error surfaced during testing). I used the following
pattern:

refcount=$(dpkg-query -f '${db:Status-Abbrev} ${binary:Package}\n' \
-W $package | grep '^i' | wc -l)
if [ $refcount -eq 0 ] ; then 
: no binaries left, remove stuff
fi

[1]
https://codesearch.debian.net/perpackage-results/DPKG_MAINTSCRIPT_PACKAGE_REFCOUNT/2/page_0


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-8
ii  libc62.19-22
ii  liblzma5 5.1.1alpha+20120614-2.1
ii  libselinux1  2.3-2+b1
ii  tar  1.28-2
ii  zlib1g   1:1.2.8.dfsg-2+b1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  1.1~exp14

-- no debconf information

Bug#595112: /usr/bin/dpkg-maintscript-helper: Please provide helper for moving a conffile between packages

[Felipe Sateler]

On Tue, 31 Jul 2012 20:47:06 +0200 Raphael Hertzog  wrote:
> On Tue, 31 Jul 2012, Josh Triplett wrote:
> > Consider the original motivation for this.  You have a package A, which
> > contains a daemon B and an init script /etc/init.d/B.  You split B and
> > its init script (and any other configuration files for it) into its own
> > package, which A does not depend on.  If installing B, you want to
> > preserve the configuration of B.  B didn't exist beforehand, so no
> > package exists for A to declare a Breaks against.  However, nothing
> > guarantees that the user will install B at the same time as upgrading A.
> > In particular, it seems highly likely that a user who wants B will
> > upgrade A, read the NEWS.Debian file, and then choose whether to install
> > B.
>
> OK so we really need a "recover_conffile" which would be used in
> package2 and would move a .dpkg-bak copy in its original place.

In systemd, we split a new package systemd-container. We used the
approach to rm_conffile in systemd for the appropriate version, and
added the following snippet to systemd-container:

machine_policy=/etc/dbus-1/system.d/org.freedesktop.machine1.conf
if [ "$1" = configure ] && [ -z "$2" ] && [ -f
${machine_policy}.dpkg-bak ] ; then
   md5sum="$(md5sum ${machine_policy} | sed -e 's/ .*//')"
   old_md5sum="$(dpkg-query -W -f='${Conffiles}' systemd-container | \
   sed -n -e "\' ${machine_policy} ' { s/
obsolete$//; s/.* //; p }")"
   # On new installs, if the policy file was preserved on systemd upgrade
   # by dpkg-maintscript helper, copy it back if the new file has not
been modified yet
   if [ "$md5sum" = "$old_md5sum" ] ; then
   mv ${machine_policy}.dpkg-bak ${machine_policy}
   fi
fi

Because this is a new package, we test -z "$2". If this was a move
between pre-existing packages, then the test should be with dpkg
--compare-versions

So far we have not received bugs about this usage.

A caveat to be aware of, is that the advice given by the man page to
use the version where the rm_conffile command is added is not
appropriate for this use case: because now the file is owned by a
different package, one should not try to remove the file in a version
later than the one that actually stops shipping the file. This implies
that if one moves a conffile between packages but forgets to add the
maintscript helpers, and adds the helpers in a later version, then the
orphaned conffile will remain if the new package is not installed.
This is unfortunate but we did not find a way to reliably determine
when the file can actually be removed.

Please implement this helper in dpkg-maintscript-helper; it seems we
will need this a lot if we decide split up the systemd package
further.

Saludos

Conffiles

[Felipe Sateler]

Do conffiles have to be regular files? Policy does not seem to be
explicit about this (although I'd be happy to be proven wrong on this),
it seems to just talk about files. 

-- 
Saludos,
Felipe Sateler



--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Conffiles

[Felipe Sateler]

On Sun, 2010-01-03 at 14:50 -0800, Russ Allbery wrote:
 Felipe Sateler fsate...@gmail.com writes:
 
  Do conffiles have to be regular files? Policy does not seem to be
  explicit about this (although I'd be happy to be proven wrong on this),
  it seems to just talk about files.
 
 I don't believe that listing symlinks as conffiles works properly at the
 moment.  See #421344.  It doesn't make any sense to list a directory as a
 conffile.  I think that exhausts all the non-regular files that can be in
 a Debian package.

Thanks for the quick answer. FWIW, this question comes because
checkinstall currently tags everything as a conffile, which caused dpkg
to fail when directories were tagged.

-- 
Saludos,
Felipe Sateler



--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Enhancing 3.0 (git) source package format

[Felipe Sateler]

On Sun, 2009-11-08 at 22:44 +0100, Tollef Fog Heen wrote:
 ]] Goswin von Brederlow 
 
 | Tollef Fog Heen tfh...@err.no writes:
 | 
 |  ]] Goswin von Brederlow 
 |  | My feeling is that 3.0 (git) format adds bloat to the source packages
 |  | that hardly anyone ever uses, makes it that much harder for any
 |  | non-git user to edit the source and is of little extra value when the
 |  | maintainers git is month or years further along.
 | 
 |  Even if the upstream VCS has moved on, you save a bit of bandwidth by
 |  having something that comes with half the history, even if you don't
 |  have all of it.
 | 
 | Weigh that against the bandwidth spend for mirrors and for people that
 | do not need or want the history and the extra cost in terms of needing
 | more CD/DVD images to contain a source snapshot. Also the cost for
 | snapshot.debian.org having to have the extra bloat for every single
 | version uploaded. For a worst case take linux-2.6 as example.
 
 If we (as I do) consider history part of the source, that size increase
 is irrelevant.
 
 | Also why would you download the source package in the first place if
 | what you really want is a git checkout. The extra bandwidth for a git
 | checkout would only be as much as the 3.0 (git) format would lack in
 | history.
 
 Because I want to add a patch that changes a behaviour in a stable
 package, and I want to add that patch in a way that gives me the least
 work, both when writing it, but also when bringing it forward.  Also, my
 mirror might be local; git.d.o and random upstream repositories
 certainly are not.

It's possible to specify a (signed) tag somewhere. You don't need a
separate blurb for very release.



-- 
Saludos,
Felipe Sateler



--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: New Build-Options field and build-arch option, please review

[Felipe Sateler]

El 10/07/08 18:02 Raphael Hertzog escribió:
 Hello,

 in order to fix #229357 I decided to add a new Build-Options field.
 I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS.
 And I added support for a build-arch option, that if present, will let
 dpkg-buildpackage call debian/rules build-arch and build-indep.

 It's not obvious that this was the right choice when you think of the
 currently existing build options but once you start thinking of possible
 additions (as requested in #489771), it becomes more evident that it makes
 sense. Even if some build options should really only be used in
 the field while others should only be used in the environment variable,
 the possibility to override the former with the latter is nice.

I'm not really sure this is right. There are two things that we want to do 
here: declare that a package supports something, and asking the package to do 
something. This difference is blurred now, and I think it is confusing.
OTOH, it gives the benefit of being able to ignore the package capabilities 
via the environment (ie, unset a given option).
I fear it will give rise to abuses such as setting parallel=n in the control 
file.


Saludos,
Felipe Sateler


signature.asc
Description: This is a digitally signed message part.

Bug#229357: New Build-Options field and build-arch option, please review

[Felipe Sateler]

El 10/07/08 18:02 Raphael Hertzog escribió:
 Hello,

 in order to fix #229357 I decided to add a new Build-Options field.
 I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS.
 And I added support for a build-arch option, that if present, will let
 dpkg-buildpackage call debian/rules build-arch and build-indep.

 It's not obvious that this was the right choice when you think of the
 currently existing build options but once you start thinking of possible
 additions (as requested in #489771), it becomes more evident that it makes
 sense. Even if some build options should really only be used in
 the field while others should only be used in the environment variable,
 the possibility to override the former with the latter is nice.

I'm not really sure this is right. There are two things that we want to do 
here: declare that a package supports something, and asking the package to do 
something. This difference is blurred now, and I think it is confusing.
OTOH, it gives the benefit of being able to ignore the package capabilities 
via the environment (ie, unset a given option).
I fear it will give rise to abuses such as setting parallel=n in the control 
file.


Saludos,
Felipe Sateler


signature.asc
Description: This is a digitally signed message part.

Re: Another multiarch decision

[Felipe Sateler]

Goswin von Brederlow wrote:

 Raphael Hertzog [EMAIL PROTECTED] writes:
 
 On Thu, 26 Jun 2008, Goswin von Brederlow wrote:
 So I think for Multi-Arch: abi packages the /usr/share/doc/package
 in its entirety should be renamed and now there is a choice to make:

 I like none of your suggestions. I'd like to suggest to rely on the
 work done by Tollef that lets dpkg skip some files in packages. The first
 purpose was to strip doc and locale data in some embedded usage
 but it could be improved with new rules that exclude such common
 name spaces for package which are for another architecture
 than the current one.

 Cheers,
 
 So when I install iceweasel 32bit on amd64 (for stupid plugins) I will
 have no copyright, changelog nor license? I doubt that would be legal.
 Even for libaries there is no garanty that the native flavour of a
 library will be present when another architectures flavour is
 installed.
 
 If a user wants to skip them that is their problem but Debian shipping
 a dpkg that skips them allways or by default would be problematic.

Maybe install the first one and skip the next? ie, if I install iceweasel 32
bits first, then /u/s/d/iceweasel gets installed. When I install the amd64
version, /u/s/d/iceweasel gets skipped.

Another option would be for dpkg to automatically assume that each arch
Replaces: the same package for other archs, and so it will just overwrite said
files.

-- 

  Felipe Sateler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#229357: Build-Options

[Felipe Sateler]

El 23/06/08 02:37 Raphael Hertzog escribió:

   I don't know if we want to put both in the same module or if we need to
   come up with a different name (or a sub-module maybe).
 
  I can try doing this, although I couldn't find an appropriate name
  (perhaps Source::BuildOptions?). The idea would be to add one function
  per build option, or one function that processes them all? I think it's
  best to do one function per build option, since an option can touch any
  part of the process.

 I'm not yet 100% sure what the best design is. I think both
 DEB_BUILD_OPTIONS and Build-Options are going to be closely tied anyway...
 Build-Options is a way to express that the package supports a set
 of functionalities and often those will be enabled through a keyword
 in DEB_BUILD_OPTIONS.

 As such, it probably makes sense to add support for both in the same
 module but with different commands to allow checking one set or the other
 or both.

I'm not really sure this is a good idea. The way I see it, Build-Options is 
most useful for declaring that the package handles something that would break 
a normal package (such as build-arch). Thus, I think they will be boolean (or 
should, at least: I don't see the usefulness of parallel=n in Build-Options). 
DEB_BUILD_OPTIONS doesn't have these characteristics, as a package that 
doesn't handle a given option simply ignores it, and that options can have 
any type. As such, I think it is a good idea to provide separate modules, 
since it makes the Build-Options support simpler.


Saludos,
Felipe Sateler


signature.asc
Description: This is a digitally signed message part.

Bug#229357: Build-Options

[Felipe Sateler]

El 23/06/08 09:45 Felipe Sateler escribió:
 El 23/06/08 02:37 Raphael Hertzog escribió:
I don't know if we want to put both in the same module or if we need
to come up with a different name (or a sub-module maybe).
  
   I can try doing this, although I couldn't find an appropriate name
   (perhaps Source::BuildOptions?). The idea would be to add one function
   per build option, or one function that processes them all? I think it's
   best to do one function per build option, since an option can touch any
   part of the process.
 
  I'm not yet 100% sure what the best design is. I think both
  DEB_BUILD_OPTIONS and Build-Options are going to be closely tied
  anyway... Build-Options is a way to express that the package supports a
  set of functionalities and often those will be enabled through a keyword
  in DEB_BUILD_OPTIONS.
 
  As such, it probably makes sense to add support for both in the same
  module but with different commands to allow checking one set or the other
  or both.

 I'm not really sure this is a good idea. The way I see it, Build-Options is
 most useful for declaring that the package handles something that would
 break a normal package (such as build-arch). Thus, I think they will be
 boolean (or should, at least: I don't see the usefulness of parallel=n in
 Build-Options). DEB_BUILD_OPTIONS doesn't have these characteristics, as a
 package that doesn't handle a given option simply ignores it, and that
 options can have any type. As such, I think it is a good idea to provide
 separate modules, since it makes the Build-Options support simpler.

Also, there is another important difference: Build-Options are specified by 
the package, while DEB_BUILD_OPTIONS are specified by the builder. I think it 
can be confusing if both are in the same module.


Saludos,
Felipe Sateler


signature.asc
Description: This is a digitally signed message part.

Bug#229357: Build-Options

[Felipe Sateler]

El 22/06/08 05:15 Raphael Hertzog escribió:
 Hi,

 On Sat, 21 Jun 2008, Felipe Sateler wrote:
  Attaching a version against current master (since this can't make it to
  lenny anyway).
 
  PS: an (N)ACK would be nice.

 We have received your patch.

Thanks for the response.

 Your patch would be even better if it was 
 complete: please update the documentation of dpkg-buildpackage accordingly.

OK. This means editing man/dpkg-buildpackage.1?

 But I have some other remarks, see below.

 Last time we discussed this idea within the team, Frank wanted to
 handle it, but it's been a long time since we had this discussion. Frank,
 do you still have time/plans for this?

  +my $source = Dpkg::Control-new()-get_source();
  +if (defined($source-{Build-Options}) ) {
  +# The build options are comma-separated, with optional spaces
  +my @build_options = split( / *, */, $source-{Build-Options} );

 Please use \s*,\s*.

  +if( grep(/\bbuild-arch\b/, @build_options)  $binaryonly eq -B) {

 Please match the keyword in its entirety: /^build-arch$/

Both done (locally, I will submit again when the documentation is done).


  +   $buildtarget = build-arch;
  +}
  +}

 As we will probably add more Build-Options over time, we probably want to
 move this processing in a dedicated module... but we already have
 Dpkg::BuildOptions which handles DEB_BUILD_OPTIONS.

 I don't know if we want to put both in the same module or if we need to
 come up with a different name (or a sub-module maybe).

I can try doing this, although I couldn't find an appropriate name (perhaps 
Source::BuildOptions?). The idea would be to add one function per build 
option, or one function that processes them all? I think it's best to do one 
function per build option, since an option can touch any part of the process.


 The discussion in the bug log also suggest to use Standards-Version as a
 source of implicit build-options. If policy 4.0 mandates the build-arch
 target, then the simple fact that Standards-Version = 4.0 can be assumed
 as having Build-Options: build-arch. I like this idea and would like to
 see it implemented in this patch.

This seems simple enough. I'll try doing this.


Saludos,
Felipe Sateler


signature.asc
Description: This is a digitally signed message part.

Bug#229357: Build-Options

[Felipe Sateler]

Attaching a version against current master (since this can't make it to lenny 
anyway). 

PS: an (N)ACK would be nice.

Saludos,
Felipe Sateler
From c738302e1c913cb23bd54cf9059f63580018ed0b Mon Sep 17 00:00:00 2001
From: Felipe Sateler [EMAIL PROTECTED]
Date: Thu, 14 Feb 2008 01:11:11 -0300
Subject: [PATCH] Add support for Build-Options.

Add Build-Options as a legal keyword in the source control file.
Also implement build-arch as the first build option. This option
causes dpkg-buildpackage to call debian/rules with the build-arch
target if called with the -B option.
---
 scripts/Dpkg/Fields.pm   |2 +-
 scripts/dpkg-buildpackage.pl |   13 -
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/scripts/Dpkg/Fields.pm b/scripts/Dpkg/Fields.pm
index 6504a1f..cb7325e 100644
--- a/scripts/Dpkg/Fields.pm
+++ b/scripts/Dpkg/Fields.pm
@@ -15,7 +15,7 @@ our %EXPORT_TAGS = ('list' = [qw(%control_src_fields %control_pkg_fields
 # Some variables (list of fields)
 our %control_src_fields;
 our %control_pkg_fields;
-$control_src_fields{$_} = 1 foreach (qw(Bugs Dm-Upload-Allowed
+$control_src_fields{$_} = 1 foreach (qw(Bugs Build-Options Dm-Upload-Allowed
 Homepage Origin Maintainer Priority Section Source Standards-Version
 Uploaders Vcs-Browser Vcs-Arch Vcs-Bzr Vcs-Cvs Vcs-Darcs Vcs-Git Vcs-Hg
 Vcs-Mtn Vcs-Svn));
diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
index 93d72a1..31631a7 100755
--- a/scripts/dpkg-buildpackage.pl
+++ b/scripts/dpkg-buildpackage.pl
@@ -16,6 +16,7 @@ use Dpkg::Version qw(check_version);
 use Dpkg::Changelog qw(parse_changelog);
 use Dpkg::Arch qw(get_build_arch debarch_to_gnutriplet);
 use Dpkg::Vendor qw(get_current_vendor);
+use Dpkg::Control;
 
 textdomain(dpkg-dev);
 
@@ -101,6 +102,7 @@ my $checkbuilddep = 1;
 my $signsource = 1;
 my $signchanges = 1;
 my $diffignore = '';
+my $buildtarget = 'build';
 my $binarytarget = 'binary';
 my $targetarch = my $targetgnusystem = '';
 
@@ -339,6 +341,15 @@ unless ($sourceonly) {
 my $pv = ${pkg}_$sversion;
 my $pva = ${pkg}_${sversion}_$arch;
 
+my $source = Dpkg::Control-new()-get_source();
+if (defined($source-{Build-Options}) ) {
+# The build options are comma-separated, with optional spaces
+my @build_options = split( / *, */, $source-{Build-Options} );
+if( grep(/\bbuild-arch\b/, @build_options)  $binaryonly eq -B) {
+	$buildtarget = build-arch;
+}
+}
+
 if ($checkbuilddep) {
 if ($admindir) {
 	push @checkbuilddep_args, --admindir=$admindir;
@@ -369,7 +380,7 @@ unless ($binaryonly) {
 chdir($dir) or failure(chdir $dir);
 }
 unless ($sourceonly) {
-withecho(@debian_rules, 'build');
+withecho(@debian_rules, $buildtarget);
 withecho(@rootcommand, @debian_rules, $binarytarget);
 }
 if ($usepause 
-- 
1.5.5.4



signature.asc
Description: This is a digitally signed message part.

Bug#229357: Build-Options

[Felipe Sateler]

Attaching a newer version of the patch that does a better search for the 
options. The search should be put probably on a subroutine, but I'm not 
really sure where, and there is only one build option for now, so it's not a 
major problem.

-- 
Felipe Sateler
From ab2945d9147938ef83a7e05922d995d66afc4a61 Mon Sep 17 00:00:00 2001
From: Felipe Sateler [EMAIL PROTECTED]
Date: Thu, 14 Feb 2008 01:11:11 -0300
Subject: [PATCH] Add support for Build-Options.

Add Build-Options as a legal keyword in the source control file.
Also implement build-arch as the first build option. This option
causes dpkg-buildpackage to call debian/rules with the build-arch
target if called with the -B option.
---
 scripts/Dpkg/Fields.pm   |2 +-
 scripts/dpkg-buildpackage.pl |   13 -
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/scripts/Dpkg/Fields.pm b/scripts/Dpkg/Fields.pm
index a41fab7..64ad047 100644
--- a/scripts/Dpkg/Fields.pm
+++ b/scripts/Dpkg/Fields.pm
@@ -15,7 +15,7 @@ our %EXPORT_TAGS = ('list' = [qw(%control_src_fields %control_pkg_fields
 # Some variables (list of fields)
 our %control_src_fields;
 our %control_pkg_fields;
-$control_src_fields{$_} = 1 foreach (qw(Bugs Dm-Upload-Allowed
+$control_src_fields{$_} = 1 foreach (qw(Bugs Build-Options Dm-Upload-Allowed
 Homepage Origin Maintainer Priority Section Source Standards-Version
 Uploaders Vcs-Browser Vcs-Arch Vcs-Bzr Vcs-Cvs Vcs-Darcs Vcs-Git Vcs-Hg
 Vcs-Mtn Vcs-Svn));
diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
index 6e1dc0e..cc1e28d 100755
--- a/scripts/dpkg-buildpackage.pl
+++ b/scripts/dpkg-buildpackage.pl
@@ -14,6 +14,7 @@ use Dpkg::BuildOptions;
 use Dpkg::Compression;
 use Dpkg::Version qw(check_version);
 use Dpkg::Changelog qw(parse_changelog);
+use Dpkg::Control;
 
 textdomain(dpkg-dev);
 
@@ -99,6 +100,7 @@ my $checkbuilddep = 1;
 my $signsource = 1;
 my $signchanges = 1;
 my $diffignore = '';
+my $buildtarget = 'build';
 my $binarytarget = 'binary';
 my $targetarch = my $targetgnusystem = '';
 
@@ -320,6 +322,15 @@ unless ($sourceonly) {
 my $pv = ${pkg}_$sversion;
 my $pva = ${pkg}_${sversion}_$arch;
 
+my $source = Dpkg::Control-new()-get_source();
+if (defined($source-{Build-Options}) ) {
+# The build options are comma-separated, with optional spaces
+my @build_options = split( / *, */, $source-{Build-Options} );
+if( grep(/\bbuild-arch\b/, @build_options)  $binaryonly eq -B) {
+	$buildtarget = build-arch;
+}
+}
+
 if ($checkbuilddep) {
 if ($admindir) {
 	push @checkbuilddep_args, --admindir=$admindir;
@@ -350,7 +361,7 @@ unless ($binaryonly) {
 chdir($dir) or failure(chdir $dir);
 }
 unless ($sourceonly) {
-withecho(@debian_rules, 'build');
+withecho(@debian_rules, $buildtarget);
 withecho(@rootcommand, @debian_rules, $binarytarget);
 }
 if ($usepause 
-- 
1.5.4.4



signature.asc
Description: This is a digitally signed message part.

Bug#229357: Am I missing something?

[Felipe Sateler]

Why is it taking so long implement Build-Options? It seems to me that the 
implementation is trivial: right before actually doing something (ie: 
checking build-dependencies), check for the Build-Options (plus adding it to 
the legal fields). The attached patch does that. 
Or is there some other stuff to do?

-- 
Felipe Sateler
From 821c5ae3860f0314daf0fa2c19a7d36f2c5c2dcb Mon Sep 17 00:00:00 2001
From: Felipe Sateler [EMAIL PROTECTED]
Date: Thu, 14 Feb 2008 01:11:11 -0300
Subject: [PATCH] Add support for Build-Options.

Add Build-Options as a legal keyword in the source control file.
Also implement build-arch as the first build option. This option
causes dpkg-buildpackage to call debian/rules with the build-arch
target if called with the -B option.
---
 scripts/Dpkg/Fields.pm   |2 +-
 scripts/dpkg-buildpackage.pl |   11 ++-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/scripts/Dpkg/Fields.pm b/scripts/Dpkg/Fields.pm
index f1b9df3..ebc1e1e 100644
--- a/scripts/Dpkg/Fields.pm
+++ b/scripts/Dpkg/Fields.pm
@@ -15,7 +15,7 @@ our %EXPORT_TAGS = ('list' = [qw(%control_src_fields %control_pkg_fields
 # Some variables (list of fields)
 our %control_src_fields;
 our %control_pkg_fields;
-$control_src_fields{$_} = 1 foreach (qw(Bugs Dm-Upload-Allowed
+$control_src_fields{$_} = 1 foreach (qw(Bugs Build-Options Dm-Upload-Allowed
 Homepage Origin Maintainer Priority Section Source Standards-Version
 Uploaders Vcs-Browser Vcs-Arch Vcs-Bzr Vcs-Cvs Vcs-Darcs Vcs-Git Vcs-Hg
 Vcs-Mtn Vcs-Svn));
diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
index 72854dd..25f54c5 100755
--- a/scripts/dpkg-buildpackage.pl
+++ b/scripts/dpkg-buildpackage.pl
@@ -14,6 +14,7 @@ use Dpkg::BuildOptions;
 use Dpkg::Compression;
 use Dpkg::Version qw(check_version);
 use Dpkg::Changelog qw(parse_changelog);
+use Dpkg::Control;
 
 textdomain(dpkg-dev);
 
@@ -99,6 +100,7 @@ my $checkbuilddep = 1;
 my $signsource = 1;
 my $signchanges = 1;
 my $diffignore = '';
+my $buildtarget = 'build';
 my $binarytarget = 'binary';
 my $targetarch = my $targetgnusystem = '';
 
@@ -299,6 +301,13 @@ unless ($sourceonly) {
 my $pv = ${pkg}_$sversion;
 my $pva = ${pkg}_${sversion}_$arch;
 
+my $source = Dpkg::Control-new()-get_source();
+if (defined($source-{Build-Options}) ) {
+if($source-{Build-Options} =~ /build-arch/  $binaryonly eq -B) {
+	$buildtarget = build-arch;
+}
+}
+
 if ($checkbuilddep) {
 if ($admindir) {
 	push @checkbuilddep_args, --admindir=$admindir;
@@ -329,7 +338,7 @@ unless ($binaryonly) {
 chdir($dir) or failure(chdir $dir);
 }
 unless ($sourceonly) {
-withecho(@debian_rules, 'build');
+withecho(@debian_rules, $buildtarget);
 withecho(@rootcommand, @debian_rules, $binarytarget);
 }
 if ($usepause 
-- 
1.5.4.1



signature.asc
Description: This is a digitally signed message part.

Re: Is it possible to make a deb package in non-debian system but only dpkg installed?

[Felipe Sateler]

Inuk You wrote:

 So once I've installed dpkg and checkinstall in the system.
 Is it problem to try to make .deb in non-debian system? (but dpkg is
 installed)

checkinstall assumes that you are on a debian system when building a deb
package. Wether this is the root of your problem or not is another issue,
but it will most probably fail.

-- 

  Felipe Sateler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]