Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support input control files #6

Open
GoogleCodeExporter opened this issue Jun 12, 2015 · 3 comments
Open

Support input control files #6

GoogleCodeExporter opened this issue Jun 12, 2015 · 3 comments

Comments

@GoogleCodeExporter
Copy link


Sometimes project authors might prefer to use an already available 
control file, instead of having ant-deb-task generate one. It would
be useful if you could specify a pre-existing control file, instead
of having to fill out all the fields. For example:

<deb todir="dist" control="plaf/debian/control" ... > 

Furthermore, it would be even better if it was possible to override
values in the given control file with ones specified in an attribute
or nested element. This becomes especially useful when creating 
packages for different architectures, which typically use the the 
same information for each control field except architecture. For 
example:

<deb control="plaf/debian/control" architecture="i386" ...>
  ...
  <tarfileset prefix="/usr/lib" dir="build/lib" includes="*.so" />
</deb>

<deb control="plaf/debian/control" architecture="amd64" ...>
  ...
  <tarfileset prefix="/usr/lib" dir="build/lib64" includes="*.so" />
</deb>

What do you think?

Original issue reported on code.google.com by kevin.mcguinness@gmail.com on 30 Jan 2008 at 7:05

@GoogleCodeExporter
Copy link
Author

The use case you are describing is interesting, not sure that supporting 
existing
control files is the best solution though. Could be.

In this case we would need a control file parser, right?

One issue I am seeing with this approach is that it is not solving the more 
general
problem. If you need to generate very similar packages, you will have 
duplication not
in building the control file, but also in putting together the actual payload, 
all
the tarfileset-s.

An alternative solution that you can use right now is to create an Ant macro 
that
uses as parameter the variable parts (the architecture and lib dir in your 
example)
and then call that macro twice to build the two .debs.

What do you think about that?

Original comment by marius.s...@gmail.com on 31 Jan 2008 at 6:05

@GoogleCodeExporter
Copy link
Author


Yes, the macro approach is also a very good solution. I was using this
but it got me thinking that since often you need to put together preinst, 
postinst etc. files anyway, writing a control file wouldn't be too much 
extra bother for a cleaner ant script. Of course, without the macro, the
tarfileset problem you mentioned remains (on a side note, it doesn't seem
possible to include tarfilesets by refid..)

Writing a control file parser should be simple enough, the format isn't too
complicated. However, I think I understand you when you say that supporting
existing control files mightn't be the best idea: it does kinda expose the
internals/details of deb package formats, which might be better left hidden.
Also, a single point of configuration is better than duplicating things like
package names or versions externally




Original comment by kevin.mcguinness@gmail.com on 31 Jan 2008 at 7:03

@GoogleCodeExporter
Copy link
Author

Let's leave the issue open for now, with low priority.

Original comment by marius.s...@gmail.com on 31 Jan 2008 at 7:17

  • Changed state: Accepted
  • Added labels: Priority-Low
  • Removed labels: Priority-Medium

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant