[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Few questions

Neil Williams wrote:
> On Mon, 29 Jan 2007 16:08:39 +0800
> Thomas Goirand <thomas@goirand.fr> wrote:
>> I have few questions that would help me to solve things in my
>> package. I have package1 and package2 being same but with different
>> dependencies, so the user can choose between them.
>> First, if my package produces many binaryies, is it ok to do symlinks
>> of the postinst if they are same. Like:
>> debian/package1.postinst would link to debian/package2.postinst
> What happens then if the user chooses to install package 1 without
> package 2?

My control file is done this way:

Package: package1
Replaces: package2

Package: package2
Replaces: package1

The only thing that differs from both packages are dependencies, nothing

> Note that dpkg-buildpackage will try to retain symlinks that
> exist in the debian/ directory and you can easily end up with a package
> containing a symlink to /home/thomas/foo which will break on any other
> system, even if the user is called Thomas!

> You can use symlinks in the upstream source, maybe in SVN etc., but
> when you prepare a directory to build the Debian package, you must take
> care that files in debian/ are actual files and that symlinks in
> debian/ are correctly installed so as to symlink to the final location
> under /usr/ etc.

I didn't express myself correctly. My goal was to do, in the debian folder:

ln -s package1.postinst package2.postinst

so that way I don't forget to copy over modifications from one postinst
to another. Is that possible or forbidden?

> Using environment variables could let you down (the environment is
> subject to user control) - it could be more reliable to test for the
> existence of an executable file /usr/bin/package1 or /usr/bin/package2
> etc. Otherwise, your maintainer scripts could fail under a chroot or
> similar.

Ok. If I understand correctly, package1 and package2 could have
different files installed just in order for me to test, right? Very good
idea and easy to implement. Thanks for the idea.

>> Third, as I have debian/package1.cron.d and debian/package2.cron.d
>> being the same, I've renamed them debian/package1.package1.cron.d and
>> debian/package2.package1.cron.d and used dh_installcron
>> --name=package1 to be sure that those 2 config files are same. But
>> when I look in /etc/cron.d there is no package1 cron script, even if
>> it's in debian/package2/etc/cron.d/package1 when I have a look after
>> a build. Any idea why?
> The package1 prefix is probably being stripped - check how the cron
> file is being prepared upstream. You may be better off using separate
> files that call their own packages using hardcoded strings.
> The other alternative is to have the cron file detect which package is
> installed (maybe by testing if /usr/bin/foo1 is an executable file
> etc.) so that there is only one cron file for package1 or package2 but
> it knows how to handle whichever is installed.

Both cron script are exactly identical. I don't need to do something
different, just to make it have one unique name for both package,
because when you replace package1 by package2 (or vice versa), there is
twice the same cron as it's not removed (because marked as conf file),
and it's very problematic. Anyway, my problem is that the cron job seems
NOT installed after dpkg -i, and that's what I'd like to fix.

> Can the user choose to install package1 and package2 on the same system
> or have you got a Conflict: setup?

They Replaces: each other.


P.S: Thanks for the reply.

Reply to: