Bug#703201: Add an option to process per-arch/per-os *and* normal install files

[Gergely Nagy]

> "Lisandro" == Lisandro Damián Nicanor Pérez Meyer  
> writes:

Lisandro> On Tuesday 01 September 2015 19:49:06 Dmitry Shachnev wrote:
>> On Tue, 01 Sep 2015 10:56:17 +0200, Gergely Nagy wrote:
>> > This can easily be done with dh-exec now, with much nicer syntax than
>> > what I proposed two years ago:
>> > 
>> > Instead of foo.install-common, foo.install.$os, foo.install.$arch, one
>> 
>> > can use a single executable foo.install file, with some special markup:
>> Yes, we (the Qt maintainers) have already been thinking about using 
dh-exec.
>> We don't want to change existing packages as our current code works fine,
>> but we will definitely look at it if we need it in our next packages.
>> > Since I have a little bit of free time, how about this:
>> > 
>> > If foo.install.common exists, auto-include foo.install.$arch and
>> > foo.install.$os (if they exist), provided that foo.install is 
executable
>> > and uses dh-exec.
>> > 
>> > Alternatively, an executable foo.install, and executable
>> > foo.install.$arch/$os could also be a trigger, so foo.install.common
>> > wouldn't be required, and could be rolled into foo.install.
>> 
>> I don't think this is needed. A single file with architecture- or
>> OS-specific lines is much simplier to use and maintain.

Lisandro> Just for the record: we are currently using a hacked -common 
-arch approach, 
Lisandro> but having a special syntax in .install files would be just 
awesome.

Lisandro> Having the possibility to add negations like [!linux] would also 
be just cool. 
Lisandro> Ie, much in the current way we can manage build dependencies.

That works right now with dh-exec. It supports all wildcards
dpkg-architecture does (it uses that under the hood). Support for the
syntax is in stable too, and dh-exec is trivial to backport to
oldstable, if so need be.

So, you can write this right now:

,
| #! /usr/bin/dh-exec
| [hurd-i386] this-is-hurd-i386-only
| [linux-any] this-is-linux-only
| [!kfreebsd-amd64] this-is-not-for-kfreebsd-amd64
| [any-i386 any-powerpc] this-is-complicated
`

This works for all debhelper scripts one can make executable, not only
foo.install files. (Though I've no idea why it would be useful anywhere
else, but hey!)

-- 
|8]

Bug#703201: Add an option to process per-arch/per-os *and* normal install files

[Lisandro Damián Nicanor Pérez Meyer]

On Tuesday 01 September 2015 19:49:06 Dmitry Shachnev wrote:
> Hi Gergely,
> 
> On Tue, 01 Sep 2015 10:56:17 +0200, Gergely Nagy wrote:
> > This can easily be done with dh-exec now, with much nicer syntax than
> > what I proposed two years ago:
> > 
> > Instead of foo.install-common, foo.install.$os, foo.install.$arch, one
> 
> > can use a single executable foo.install file, with some special markup:
> Yes, we (the Qt maintainers) have already been thinking about using dh-exec.
> We don't want to change existing packages as our current code works fine,
> but we will definitely look at it if we need it in our next packages.
> > Since I have a little bit of free time, how about this:
> > 
> > If foo.install.common exists, auto-include foo.install.$arch and
> > foo.install.$os (if they exist), provided that foo.install is executable
> > and uses dh-exec.
> > 
> > Alternatively, an executable foo.install, and executable
> > foo.install.$arch/$os could also be a trigger, so foo.install.common
> > wouldn't be required, and could be rolled into foo.install.
> 
> I don't think this is needed. A single file with architecture- or
> OS-specific lines is much simplier to use and maintain.

Just for the record: we are currently using a hacked -common -arch approach, 
but having a special syntax in .install files would be just awesome.

Having the possibility to add negations like [!linux] would also be just cool. 
Ie, much in the current way we can manage build dependencies.


-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#703201: Add an option to process per-arch/per-os *and* normal install files

[Gergely Nagy]

This can easily be done with dh-exec now, with much nicer syntax than
what I proposed two years ago:

Instead of foo.install-common, foo.install.$os, foo.install.$arch, one
can use a single executable foo.install file, with some special markup:

,
| #! /usr/bin/dh-exec
| 
| ## Common stuff
| /usr/share
| 
| ## arch-specific stuff
| [any-amd64] /usr/lib/foo-amd64 /usr/lib
| [any-i386] /usr/lib/foo-i386 /usr/lib
| 
| ## os-specific stuff
| [linux-any] /usr/lib/foo-linux /usr/lib/foo/
| [freebsd-any] /usr/lib/foo-freebsd /usr/lib/foo/
`

And so on and so forth, see dh-exec-install(1). The wildcards follow the
same syntax as dpkg-architecture(1).

This approach does not require splitting the files, and only works when
everything is in a single file, which may get lengthy. If there is a
need to support some kind of inclusion, I can very easily add that to
dh-exec. It's about 5-6 lines of code, and a few handful more for tests.

Since I have a little bit of free time, how about this:

If foo.install.common exists, auto-include foo.install.$arch and
foo.install.$os (if they exist), provided that foo.install is executable
and uses dh-exec.

Alternatively, an executable foo.install, and executable
foo.install.$arch/$os could also be a trigger, so foo.install.common
wouldn't be required, and could be rolled into foo.install.

A third option would be what I suggested in 2013: an explicit #include.

I'd only implement at most one of the above, let me know which would be
the most debhelper-ish way to accomplish the task (the currently
available syntax is an option too, of course).

-- 
|8]

Bug#703201: Add an option to process per-arch/per-os *and* normal install files

[Dmitry Shachnev]

Hi Gergely,

On Tue, 01 Sep 2015 10:56:17 +0200, Gergely Nagy wrote:
> This can easily be done with dh-exec now, with much nicer syntax than
> what I proposed two years ago:
>
> Instead of foo.install-common, foo.install.$os, foo.install.$arch, one
> can use a single executable foo.install file, with some special markup:

Yes, we (the Qt maintainers) have already been thinking about using dh-exec.
We don't want to change existing packages as our current code works fine,
but we will definitely look at it if we need it in our next packages.

> Since I have a little bit of free time, how about this:
>
> If foo.install.common exists, auto-include foo.install.$arch and
> foo.install.$os (if they exist), provided that foo.install is executable
> and uses dh-exec.
>
> Alternatively, an executable foo.install, and executable
> foo.install.$arch/$os could also be a trigger, so foo.install.common
> wouldn't be required, and could be rolled into foo.install.

I don't think this is needed. A single file with architecture- or
OS-specific lines is much simplier to use and maintain.

Thanks for your help!

--
Dmitry Shachnev

signature.asc
Description: OpenPGP digital signature

Bug#703201: Add an option to process per-arch/per-os *and* normal install files

[Lisandro Damián Nicanor Pérez Meyer]

On Tue 09 Apr 2013 13:43:02 Gergely Nagy escribió:
 Lisandro Damián Nicanor Pérez Meyer lisan...@debian.org writes:
  On Sat 16 Mar 2013 18:47:51 Lisandro Damián Nicanor Pérez Meyer escribió:
  [snip]
  
  Also, as another way to achieve this, is adding the option to use
  foo.install.common
  
  So if you have foo.install.ARCH and foo.install.common, both files would
  be processed. This will not break previous behaviour.
  
  And another option will be simply allowing dh_install to accept a certain
  file:
  
  dh_install --list-file foo.install.common
 
 You can also use dh9+ and executable install files, then assemble the
 files in whatever way you want. To make it easier, I'd be happy to add
 support for this kind of thing in dh-exec, so all you would need to do
 would be:
 
 * Add dh-exec to build-depends
 * cat foo.install EOF
 #!/usr/bin/dh-exec
 #include foo.install.${DEB_HOST_ARCH}
 blah
 blah
 blah
 EOF
 * chmod +x foo.install
 
 Let me know if you're interested in using dh-exec for this task, and
 I'll add the necessary code there.

Well, we eneded up using .install-$arch, .install-$os and .install-common, 
merge them in a single .install and then call dh_install, so I guess the 
solution is quite simple. It's currently in qtbase (qt 5 base), in NEW.

Thanks a lot for offering help non the less :-)

Kinds regards, Lisandro.

-- 
Sólo porque un mensaje pueda no ser recibido no implica que no
valga la pena enviarlo.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#703201: Add an option to process per-arch/per-os *and* normal install files

[Gergely Nagy]

Lisandro Damián Nicanor Pérez Meyer lisan...@debian.org writes:

 On Sat 16 Mar 2013 18:47:51 Lisandro Damián Nicanor Pérez Meyer escribió:
 [snip]
 Also, as another way to achieve this, is adding the option to use
 foo.install.common

 So if you have foo.install.ARCH and foo.install.common, both files would be
 processed. This will not break previous behaviour.

 And another option will be simply allowing dh_install to accept a certain 
 file:

 dh_install --list-file foo.install.common

You can also use dh9+ and executable install files, then assemble the
files in whatever way you want. To make it easier, I'd be happy to add
support for this kind of thing in dh-exec, so all you would need to do
would be:

* Add dh-exec to build-depends
* cat foo.install EOF
#!/usr/bin/dh-exec
#include foo.install.${DEB_HOST_ARCH}
blah
blah
blah
EOF
* chmod +x foo.install

Let me know if you're interested in using dh-exec for this task, and
I'll add the necessary code there.

-- 
|8]


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

Bug#703201: Add an option to process per-arch/per-os *and* normal install files

[Lisandro Damián Nicanor Pérez Meyer]

Package: debhelper
Version: 9.20120909
Severity: wishlist

Hi! From current debhelper manpage:

  In some rare cases, you may want to have different versions of these files
  for different architectures or OSes. If files named debian/package.foo.ARCH
  or debian/package.foo.OS exist, where ARCH and OS are the same as the output
  of dpkg-architecture -qDEB_HOST_ARCH / dpkg-architecture 
-qDEB_HOST_ARCH_OS,
  then they will be used in preference to other, more general files.

In some not so unormal cases (like packaging Qt and KDE stuff) it would be
*really nice* to be able to tell dh_install to process both the normal
foo.install and/or foo.ARCH/foo.OS files.

In this way we could put the common stuff in foo.install and add the necessary
missing files in foo.install.ARCH and/or foo.install.OS.

This can be currently done by hacking debian/rules, but it would be nice to have
some parameters to simplify this task.

Kinds regards, Lisandro.

-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.21+edid (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages debhelper depends on:
ii  binutils2.22-8
ii  dpkg1.16.9
ii  dpkg-dev1.16.9
ii  file5.12-2
ii  html2text   1.3.2a-15
ii  man-db  2.6.3-3
ii  perl5.14.2-20
ii  po-debconf  1.0.16+nmu2

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  0.62

-- no debconf information


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

Bug#703201: Add an option to process per-arch/per-os *and* normal install files

[Lisandro Damián Nicanor Pérez Meyer]

On Sat 16 Mar 2013 18:08:07 Lisandro Damián Nicanor Pérez Meyer escribió:
 Package: debhelper
 Version: 9.20120909
 Severity: wishlist
 
 Hi! From current debhelper manpage:
 
   In some rare cases, you may want to have different versions of these
 files for different architectures or OSes. If files named
 debian/package.foo.ARCH or debian/package.foo.OS exist, where ARCH and OS
 are the same as the output of dpkg-architecture -qDEB_HOST_ARCH /
 dpkg-architecture -qDEB_HOST_ARCH_OS, then they will be used in
 preference to other, more general files.
 
 In some not so unormal cases (like packaging Qt and KDE stuff) it would be
 *really nice* to be able to tell dh_install to process both the normal
 foo.install and/or foo.ARCH/foo.OS files.
 
 In this way we could put the common stuff in foo.install and add the
 necessary missing files in foo.install.ARCH and/or foo.install.OS.
 
 This can be currently done by hacking debian/rules, but it would be nice to
 have some parameters to simplify this task.

Also, as another way to achieve this, is adding the option to use 
foo.install.common

So if you have foo.install.ARCH and foo.install.common, both files would be 
processed. This will not break previous behaviour.


-- 
If you have an apple and I have an apple and we exchange these apples then you
and I will still each have one apple. But if you have an idea and I have an
idea and we exchange these ideas, then each of us will have two ideas.
 George Bernard Shaw

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#703201: Add an option to process per-arch/per-os *and* normal install files

[Lisandro Damián Nicanor Pérez Meyer]

On Sat 16 Mar 2013 18:47:51 Lisandro Damián Nicanor Pérez Meyer escribió:
[snip]
 Also, as another way to achieve this, is adding the option to use
 foo.install.common
 
 So if you have foo.install.ARCH and foo.install.common, both files would be
 processed. This will not break previous behaviour.

And another option will be simply allowing dh_install to accept a certain 
file:

dh_install --list-file foo.install.common

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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