Re: Build Debian bin pkg from Ubunt scr pkg

Hall=F6chen!

Stefan Schlee writes:

> Torsten Bronger writes:
>
> [...]
>
>>>  -- I had to execute: "/usr/sbin/refdbd" as root and change the
>>> ownership of the "/var/lib/refdb/db" hierarchy afterwards.
>>
>> Then I have to fix this because this must not be necessary.
>> Probably it's a Sqlite config issue because with Postgres, the
>> limited privileges work fine, including properly writing the PID
>> and the log file.
>
> Simply remove the 09_refdbd_user_always_refdb_in_refdb-init.patch
> from the Ubuntu source package, the original script is ok:
>
> # create the main database
> if [ "${engine_name}" =3D "pgsql" ]; then
>     su $postgres_name -c "$MYREFDBD -a -e 0 -l 6 -u $dbadmin_name -w
> $dbadmin_password" || endScript "Check for PostgreSQL authentication prob=
lems"
> "failed"
> else
>     $MYREFDBD -a -e 0 -l 6 -u $dbadmin_name -w $dbadmin_password || endSc=
ript
> "Failed to install or upgrade main database" "failed"
> fi
>
> which means that in the sqlite(3) case the "/usr/sbin/refdb" is
> run as root.

Okay, I see that root is necessary to write the RefDB config files.

But I still don't think that in any phase it is good to start refdbd
as root.  After all, even when initialising, refdbd writes Sqlite
files that it must write later as well.

>>> ...
>> =

>> No, PID and log files are set to permissions which allow the
>> "refdb" user to write them.
>
> You are right, the permissions are set correctly.  But removing
> the above patch does not completely solve the problem for me, I
> have to execute
>
> chown -R refdb:refdb /var/lib/refdb/db
>
> after the "refdb" database is set up.

That's the problem.  I must learn Sqlite better; I'll do it this
weekend.  Initialising a database should not require more file
system privileges than writing to it.  If Sqlite doesn't agree with
me, I am disappointed.

> [...]
>
>>>  - I do not know which of the original shortcomings have already
>>> been addressed in a possible new version of Torsten's Ubuntu
>>> source package.  As I am building and installing in a Debian
>>> context, I do not know if these (or which of these) shortcomings
>>> should be handled in an Ubuntu package.
>> =

>> I didn't do anything except fixing the wrong MYREFDBCTL path above.
>> I won't have time for it until the weekend.
>> =

>> Anyway, the Ubuntu package must be built in a way that only minimal
>> modifications are necessary for Debian.  =

>
> Full ack.
>
>> I don't have any experience with packages beyond packaging RefDB,
>> let alone with packaging for Debian.  How is it done normally?  Is
>> there one "source" package (my Ubuntu package in this case) and one
>> "derived" package with a couple of meta-patches (your Debian package
>> in this case)?  How do packagers organise this?
>
> [...]
>
> The definitive sources concerning packaging for Debian are:
>
>  - the "Debian New Maintainers' Guide"
> (http://www.debian.org/doc/manuals/maint-guide/)
>
>  - the "Debian Developer's Reference"
> (http://www.debian.org/doc/manuals/developers-reference/) and
>
>  - the  "Debian Policy Manual" (http://www.debian.org/doc/debian-policy/)=
.  =


The Ubuntu people must read the same docs since the differences are
small to non-existent.  Normally, it's the other way round, i.e. the
Debian package is first.

When you have time, we'll try to get both packages as equal as
possible, then we declare the Debian version as "original" and the
Ubuntu version as "derived" because this is the normal case.  We put
both in a repo that both of us have access to, and if others take
over maintainance, the nuisance is minimal.

Tsch=F6,
Torsten.

-- =

Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: [email protected]
                                  or http://bronger-jmp.appspot.com


---------------------------------------------------------------------------=
---
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay =

ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf