Re: [RFC] dpkg-buildpackage development goal
On Mon, Oct 08, 2007 at 09:34:14PM -0300, Otavio Salvador wrote:
On the other hand one could argue that dpkg-buildpackage should
intentionally remain simple and that people are expected to write
their own wrappers or replacements if they need.
What do you think?
I personally think it ought to be kept simple since is very easy to
write other more feature-rich wrappers around it.
It needs to support all basic features of dpkg but no more then that.
In principle I agree with that.
However as a matter of fact nowadays is not that easy to switch from one
dpkg-buildpackage wrapper to the another, due to the variety of needed
configurations, different invocation APIs and such and such (here I'm
thinking at the ones I've used so far in my DD experience:
dpkg-buildpackage itself, debuild, pbuilder, cowbuilder,
{svn,bzr,git,...}-buildpackage.
*If* (I'm not sure it will) integrating some of their features directly
in dpkg-buildpackage can ease the switching from one to the other I
would say: go and implement them in dpkg-buildpackage.
Cheers.
--
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48) Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15) Bac: no, la demo scema\/right keys at the right time
signature.asc
Description: Digital signature
Re: [RFC] dpkg-buildpackage development goal
On Tue, Oct 09, 2007 at 02:13:41AM +0200, Frank Lichtenheld wrote: On the other hand one could argue that dpkg-buildpackage should intentionally remain simple and that people are expected to write their own wrappers or replacements if they need. I like this thought. On the other hand, something like integrating dpkg-sig(s) functionality might be a good thing to do. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] dpkg-buildpackage development goal
On Tue, 09 Oct 2007, Frank Lichtenheld wrote: Obviously one could attempt to merge in new features especially from debuild which reimplements dpkg-buildpackage but with many fancy additions. (While e.g. pbuilder and sbuild wrap dpkg-buildpackage but do not replace it) On the other hand one could argue that dpkg-buildpackage should intentionally remain simple and that people are expected to write their own wrappers or replacements if they need. I think this needs to be evaluated on a feature-by-feature basis. Some features should be handled in a standardized ways while some corner-case features are better left to external wrappers. It depends on how much creativity a given feature requires... when there's only one right way to do it, it should be in dpkg-buildpackage, otherwise it can be easily left out. Like Julian, I think package signatures ought to be handled at this level because only one implementation is really needed IMO. Also now that you offered a command line option (-j) for DEB_BUILD_OPTIONS=parallel=n, I think it would make sense to offer similar options for other common options like debug,nostrip (#154468). #4655 (checking versions in changelogs, if we do it) would also be a waste if it was reimplemented in various wrappers. BTW, with the BTS using the historical changelog information for its version tracking, it probably makes sense to do it. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] dpkg-buildpackage development goal
Stefano Zacchiroli [EMAIL PROTECTED] writes:
On Mon, Oct 08, 2007 at 09:34:14PM -0300, Otavio Salvador wrote:
On the other hand one could argue that dpkg-buildpackage should
intentionally remain simple and that people are expected to write
their own wrappers or replacements if they need.
What do you think?
I personally think it ought to be kept simple since is very easy to
write other more feature-rich wrappers around it.
It needs to support all basic features of dpkg but no more then that.
In principle I agree with that.
However as a matter of fact nowadays is not that easy to switch from one
dpkg-buildpackage wrapper to the another, due to the variety of needed
configurations, different invocation APIs and such and such (here I'm
thinking at the ones I've used so far in my DD experience:
dpkg-buildpackage itself, debuild, pbuilder, cowbuilder,
{svn,bzr,git,...}-buildpackage.
*If* (I'm not sure it will) integrating some of their features directly
in dpkg-buildpackage can ease the switching from one to the other I
would say: go and implement them in dpkg-buildpackage.
Personally I think it's a different problem.
A week ago I was talking to Arnaud (squashfs Debian maintainer, on Cc)
and we were talking about this problem and we think the best way to
avoid this problem is to have a common place for configuration so all
those wrappers avoid duplicated settings.
It would be better to offer a way to set and get settings in a common
way and then make all those tools to use it. This would make the
switch much easier.
--
O T A V I OS A L V A D O R
-
E-mail: [EMAIL PROTECTED] UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
-
Microsoft sells you Windows ... Linux gives
you the whole house.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] dpkg-buildpackage development goal
Frank Lichtenheld writes ([RFC] dpkg-buildpackage development goal): Since I haved hacked quite a bit on dpkg-buildpackage in the last one or two weeks I wanted to gather some comments on what people think should be the goal of dpkg-buildpackage development. I think I have an answer to this question. The interface provided by a Debian source package is that specified for debian/rules. This interface needs to be kept stable in the sense that feeding new packages to old tools, and old packages to new tools, needs to keep working. It also needs to be kept simple for packages, since we must conform to this interface in all of our packages. It used to be the case that very few programs needed to interact in any at all complicated way with source packages. But this is becoming less true, and the interfaces keep getting more feature-rich. At the moment if we want to introduce some new feature for packages to provide then either we need backward-compatibility code in every relevant package, or we need backward-compatibility code in every program which uses packages. I think dpkg-buildpackage should take up the role of being the single place where this impedance matching is done. That is, the interface for packages should be made such that it is as straightforward as possible to make a correct package, and packages' callers should rely on dpkg-buildpackage to communicate their requirements appropriately to the underlying packages with fallback if necessary. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] dpkg-buildpackage development goal
Otavio == Otavio Salvador [EMAIL PROTECTED] writes: Hello, Otavio A week ago I was talking to Arnaud (squashfs Debian Otavio maintainer, on Cc) and we were talking about this problem Otavio and we think the best way to avoid this problem is to have a Otavio common place for configuration so all those wrappers avoid Otavio duplicated settings. Otavio It would be better to offer a way to set and get settings in Otavio a common way and then make all those tools to use it. This Otavio would make the switch much easier. I think we should have one configuration file (~/.rcs-buildpackage.conf maybe?) and if needed another configuration files for specific RCS options. The latter would override the former settings. Choosing this approach means that we should have common options, I haven't had the time yet to check whether the different *-buildpackage tools share the same options. But I think it shouldn't be so complicated to patch the different tools for using the configuration file mentioned above. What do you think? Regards, Arnaud Fontaine pgpqi92Ur1PiK.pgp Description: PGP signature
[RFC] dpkg-buildpackage development goal
Hi. Since I haved hacked quite a bit on dpkg-buildpackage in the last one or two weeks I wanted to gather some comments on what people think should be the goal of dpkg-buildpackage development. dpkg-buildpackage has very seen very few changes in its feature set during its lifetime. The question is whether this was intentional or just due do all former maintainers having other priorities? Obviously one could attempt to merge in new features especially from debuild which reimplements dpkg-buildpackage but with many fancy additions. (While e.g. pbuilder and sbuild wrap dpkg-buildpackage but do not replace it) On the other hand one could argue that dpkg-buildpackage should intentionally remain simple and that people are expected to write their own wrappers or replacements if they need. What do you think? Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] dpkg-buildpackage development goal
Frank Lichtenheld [EMAIL PROTECTED] writes: On the other hand one could argue that dpkg-buildpackage should intentionally remain simple and that people are expected to write their own wrappers or replacements if they need. What do you think? I personally think it ought to be kept simple since is very easy to write other more feature-rich wrappers around it. It needs to support all basic features of dpkg but no more then that. That is my personal point of view. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
