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

Re: RFS: dhcp-probe, another try to request with a lot of update



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Matthew Palmer a écrit :
> On Thu, Nov 27, 2008 at 10:14:56PM +0100, Laurent Guignard wrote:
>> Michal ??iha?? a écrit :
>>> Hi
>>>
>>> [...]
>>>
>>> Quick look at the package:
>>>
>>> - any reason why it is Architecture: i386?
>>
>> In reason of the libraries dependency.
>> libnet1 package is for i386 architecture and dhcp_probe use it with
>> previous update of this library in order to provide specific functions
>> needed by dhcp_probe.
>>
>> #apt-cache show libnet1
>> 	Package: libnet1
> [...]
>> 	*Architecture: i386*
> 
> That shows the binary package information on your system.  If you'd run that
> on an arm system, dhcp-probe would now be an arm-only package.
> 
> Examine the source package info, or just look at
> http://packages.debian.org/sid/libnet1 for the list of architectures that a
> package is built for.
> 
> But at any rate, your argument is bollocks -- packages should have the
> architectures listed that *it* supports, regardless of it's dependencies. 
> What if libnet1 *was* an i386-only package at the moment, but then in a
> month's time someone makes it truly arch-neutral and it builds for all
> arches?  Much easier for everyone if your package doesn't need any changes
> to support more arches.

OK, that is a new information for me. I thought, before your comment,
that aptitude show xxx show all architectures available for a package
and it is not !

Thanks for information.

I have another question about architecture :
How is it possible to check if a package could be built on architecture
without the appropriate hardware ?
I can say that dhcp-probe could be build on i386 and any compatible
architectures and with the upstream notes, i can say that dhcp-probe
could be built on sparc but how to test on other architectures ?

> 
>> May be i am wrong, but i think it is impossible to build a package on
>> architectures that are not supported by needed libraries ?
> 
> It's impossible to build, yes, but that situation will be adequately dealt
> with by the autobuilders.
> 
>>> - why you manually create some directories and files? dh_install and
>>> dh_installdirs should do the job better and nicer. Anyway most of these
>>> dirs do not have to be created (examples) or look simply wrong to me
>>> (/etc/default/dhcp-probe)
> 
> [...]
> 
>> The /etc/default/dhcp-probe directory is used to store all configuration
>> files needed (one for each interface on which dhcp-probe is used). I
>> thought that it was the best solution instead of spreading all
>> configuration files directly in /etc.
> 
> dh_installinit will automatically put a default file in place if
> asked nicely.  See the appropriate man page for more details.
> 
> - Matt
> 
> 

Yes, dh_installinit will automatically put *a* default file in place.
As you noticed, it place *A* default file.
That i would like to do, is to place at least one file and i doesn't
know how many because it depends of the number of network interfaces the
host on which the package is installed has !

May be dh_installinit has the possibility to do this with --name option
but in the man page it isn't specified if the dh_installinit script
support multiple --name option. Moreover, all default option (for each
interface) if generated on fly during postinst step, is it possible to
run dh_installinit in postinst script ?
So at my level in Debian knowledge, i use ucf, as Michal saids, to do
the job. I need help to check if my ucf first time usage is correct or not.


Best regards.


- --
Laurent Guignard, Registered as user #301590 with the Linux Counter
Site : http://www.famille-guignard.org
Blog : http://blog.famille-guignard.org
Projet : http://sicontact.sourceforge.net
GULL de Villefranche sur Saône : http://www.cagull.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJMTecjcKpXFc/7oYRArjeAJ0ZYmn194qPJCkYnAVhdGyJxgRskQCfU+3X
qL1xPJzZx6fpTDoKl09Z/0M=
=y2f/
-----END PGP SIGNATURE-----


Reply to: