Re: Roadmap for the 1.15.x series
Hi! On Mon, 2009-09-07 at 16:38:53 +0200, Guillem Jover wrote: Will probably add the items from this thread to the TODO list or a wiki page. Coalesced the items from the mailing list into: http://wiki.debian.org/Teams/Dpkg/RoadMap regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Roadmap for the 1.15.x series
On Sat, 12 Sep 2009, Martin Schulze wrote: Here's a tarfile of the directory: http://people.debian.org/~joey/stuff/dpkg-multicd.cvs.tar.gz Thanks, but the conversion tool also need the CVSROOT directory, can you provide it? Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Roadmap for the 1.15.x series
On Sat, Sep 12, 2009 at 03:25:49PM +0200, Raphael Hertzog wrote:
Hi,
On Sat, 12 Sep 2009, Martin Schulze wrote:
CCing Joey for this. Joey, what would you think of merging
dpkg-multicd into dselect itself?
Not the worst idea. Please go ahead.
Cool, thanks for the quick answer.
If you're interested in the CVS history for the import, please let me know.
Why not, please make it available. But I'm not sure how to properly
integrate it in the git history without having many unbuildable
revision that would contain only that code and not the rest.
Ccing Pierre Habouzit, maybe he has an idea on how to do it properly.
1/ do the cvs - git conversion.
2/ apply all the rewrites you need to cleanse the log (commiter names
rewrite, and so on. Note that for CVS you can use a mailmap IIRC to
do that).
Make this import a new branch of the local repository, independant one.
Then there is two cases:
3a/ dpkg-multicd will live in the same location it did in the CVS.
3b/ dpkg-multicd will live in a separate directory
For 3a, you just need to merge the branch into dpkg's master, and be
done with it. If there is a Makefile{,.am} in both you'll have a huge
confict to deal with, but if there is no file name conflicts, you'll be
fine.
For 3b/ you have to move the CVS imported history into a directory
before doing the same merge as in 3a. This can be achieved really fast
with git filter-branch, then you fallback to 3a.
FWIW it's what was done in linux-2.6.git when the btrfs tree was merged.
This was discussed at lenght at the time, and most git expert agreed it
was the best way to go.
The sole problem it yields is wrt git-bisect: git-bisect will recurse
in this new branch history which you rarely want. But git-bisect is able
to prune sub-trees, so just note the last sha1 commit of the
dpkg-multicd branch before the merge to exclude it.
Second, beware that the merge commits _builds_ fine, even if it doesn't
build dpkg-multicd yet, and that you adjust the Makefiles in a latter
commit. Else it'll be a PITA for bisections as well.
That said, you should be fine.
--
·O· Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org
signature.asc
Description: Digital signature
Re: Roadmap for the 1.15.x series
Hi, On Fri, 11 Sep 2009, Guillem Jover wrote: On Mon, 2009-09-07 at 17:21:41 +0200, Raphael Hertzog wrote: On Mon, 07 Sep 2009, Guillem Jover wrote: * Clean up dpkg namespace: - Rename dpkg-ftp as dselect-ftp. I'm the maintainer of this one. Maybe it could be merged in dselect itself, it would make more sense IMO. Yeah, I had that written at some point when preparing the mail, but removed it, cannot remember why. So yes, I think it makes sense to merge even if we end up splitting dselect from the source package afterwards. But I'd keep it as the (renamed) separate binary package, as it has additional dependencies. Ok, but it's only perl the additional dependency. libnet-perl is an old package that's provided by perl-modules nowadays. - Rename dpkg-multicd as dselect-multicd. Maybe we could do the same with this one, given that the goal is to have dselect a separate source package at some point in the future. Right, would need discussing with Martin Schulze first. CCing Joey for this. Joey, what would you think of merging dpkg-multicd into dselect itself? In the long term, we want dselect to be a source package separate from dpkg and thus we'd like to avoid having a confusing name such as dpkg-multicd. To avoid handling a package rename from dpkg-multicd to dselect-multicd I suggested merging the feature in dselect itself since it doesn't add any new dependency and is not very big or difficult to maintain. As I said, I'll take care of this part. Give me your comments and I'll take care of them (we should maybe create a wiki page for the API cleanup). Sure, there's also some old function names that would need improving, and some other stuff, but we can work that out on the wiki. I just created the page: http://wiki.debian.org/Teams/Dpkg/PerlAPICleanup Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Roadmap for the 1.15.x series
Raphael Hertzog wrote: On Fri, 11 Sep 2009, Guillem Jover wrote: On Mon, 2009-09-07 at 17:21:41 +0200, Raphael Hertzog wrote: On Mon, 07 Sep 2009, Guillem Jover wrote: * Clean up dpkg namespace: - Rename dpkg-ftp as dselect-ftp. I'm the maintainer of this one. Maybe it could be merged in dselect itself, it would make more sense IMO. Yeah, I had that written at some point when preparing the mail, but removed it, cannot remember why. So yes, I think it makes sense to merge even if we end up splitting dselect from the source package afterwards. But I'd keep it as the (renamed) separate binary package, as it has additional dependencies. Ok, but it's only perl the additional dependency. libnet-perl is an old package that's provided by perl-modules nowadays. - Rename dpkg-multicd as dselect-multicd. Maybe we could do the same with this one, given that the goal is to have dselect a separate source package at some point in the future. Right, would need discussing with Martin Schulze first. CCing Joey for this. Joey, what would you think of merging dpkg-multicd into dselect itself? Not the worst idea. Please go ahead. If you're interested in the CVS history for the import, please let me know. Regards, Joey -- It's practically impossible to look at a penguin and feel angry. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Roadmap for the 1.15.x series
Hi, On Sat, 12 Sep 2009, Martin Schulze wrote: CCing Joey for this. Joey, what would you think of merging dpkg-multicd into dselect itself? Not the worst idea. Please go ahead. Cool, thanks for the quick answer. If you're interested in the CVS history for the import, please let me know. Why not, please make it available. But I'm not sure how to properly integrate it in the git history without having many unbuildable revision that would contain only that code and not the rest. Ccing Pierre Habouzit, maybe he has an idea on how to do it properly. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Roadmap for the 1.15.x series
Raphael Hertzog wrote: If you're interested in the CVS history for the import, please let me know. Why not, please make it available. But I'm not sure how to properly integrate it in the git history without having many unbuildable revision that would contain only that code and not the rest. Ccing Pierre Habouzit, maybe he has an idea on how to do it properly. Here's a tarfile of the directory: http://people.debian.org/~joey/stuff/dpkg-multicd.cvs.tar.gz Regards, Joey -- It's practically impossible to look at a penguin and feel angry. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Roadmap for the 1.15.x series
Hi Sean! On Mon, 2009-09-07 at 20:22:29 +0200, sean finney wrote: On Fri, Aug 21, 2009 at 08:20:35AM +0200, Guillem Jover wrote: - Merge back apt-exttracttemplates. - Finish to draft the spec for the debconf integration: http://wiki.debian.org/DpkgDebconfIntegration - Implement invoke hooks. - Implement db control-path printing. - Implement --reconfigure?? * Extend conffile support, merge back ucf: - Store conffiles at install time. http://wiki.debian.org/Teams/Dpkg/Proposals/ConffileDatabase - Support registering configuration files. - Add a new dpkg-conffile to handle conffiles (view, diff, rm, restore, etc). i'm happy to help with both of these, in particular the latter of the two as i think it's something that would be immensely useful to a large portion of our userbase. btw, for the next few months i'm going to have more free time than usual for debian related activities as well, so please let me know what i can do to push this forward. Cool! I was about to ask you to send the conffile patches for review to the list when I noticed you already did more than one year ago, I had completely forgotten. :/ I'll be doing the review during this month, but first I want to take care of some items from my TODO list. I want to apologize though, for what might have seemed me stone walling you on this. I lost a great deal of motivation last year due to Debian itself and due to work, and one consequence was that I dropped the ball on the conffile stuff (among other things), I've had it (and countless of other items) in mind as something to be done, but that's not always enough. thanks, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Roadmap for the 1.15.x series
On Mon, 2009-09-07 at 17:21:41 +0200, Raphael Hertzog wrote: On Mon, 07 Sep 2009, Guillem Jover wrote: * Clean up dpkg namespace: - Rename dpkg-ftp as dselect-ftp. I'm the maintainer of this one. Maybe it could be merged in dselect itself, it would make more sense IMO. Yeah, I had that written at some point when preparing the mail, but removed it, cannot remember why. So yes, I think it makes sense to merge even if we end up splitting dselect from the source package afterwards. But I'd keep it as the (renamed) separate binary package, as it has additional dependencies. - Rename dpkg-multicd as dselect-multicd. Maybe we could do the same with this one, given that the goal is to have dselect a separate source package at some point in the future. Right, would need discussing with Martin Schulze first. - Review of all APIs, cleanup, etc. Something I'd like to do pretty soon, after checking if there's anyone using those modules, but before new code starts using them, is to rename: Dpkg/Control.pm → Dpkg/Source/Control.pm Dpkg/Cdata.pm → Dpkg/Control.pm I think the rest of the modules have enough clear names, but it would make sense to check again before we mark them as a public interface. As I said, I'll take care of this part. Give me your comments and I'll take care of them (we should maybe create a wiki page for the API cleanup). Sure, there's also some old function names that would need improving, and some other stuff, but we can work that out on the wiki. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Roadmap for the 1.15.x series
On Sat, 2009-08-22 at 10:19:09 +0200, Tollef Fog Heen wrote: ]] Guillem Jover | * Extend conffile support, merge back ucf: | | - Store conffiles at install time. | http://wiki.debian.org/Teams/Dpkg/Proposals/ConffileDatabase | - Support registering configuration files. Could we add support for registering arbitrary files? Quite a few packages generate files in their postinst script (e.g. byte-compilation of elisp, python), and being able to query for who owns it using dpkg -S would be useful. Sure, it's on the TODO in git, forgot to add the list here. There's also the pending discussion we have about classes. But I'd rather concentrate on a first set of stuff to work on, I already have a tendency to try to do too much, no need to worsen it. :) regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Roadmap for the 1.15.x series
Hi! Knew had forgotten some stuff. And added comments on some of the previous items. Will probably add the items from this thread to the TODO list or a wiki page. On Fri, 2009-08-21 at 08:20:35 +0200, Guillem Jover wrote: The “merge back” development series 1.15.x == * Better integration with front-ends: - Discuss and decide about dpkg knowledge of repository information. Either push out the available file handling to the front-ends, or take full responsibility of repository package availability. - A way for front-ends to store additional information for each package. - Other stuff, would need to ask front-end developers. * Merge back localepurge: - Mostly finishing and merging the filters branch [filters]. - After that localepurge can be considered obsolete or just a way to provide config files. * Translation deb support (tdeb): - Clarify the draft (had some discussions about that with the i18n team at DebConf). - Depending on the discussions might need either (= refactor-deb) or (= filters), or other stuff. * Clean up dpkg namespace: - Rename dpkg-ftp as dselect-ftp. - Rename dpkg-multicd as dselect-multicd. - Consider changes to local dpkg-scanpackages in dpkg-multicd. - Eventual move of the method directories to /usr/lib/dselect/. * New perl modules package [libdpkg-perl]: - Move Dpkg.pm to libdpkg-perl (= c-rewrite). Actually the c-rewrite is not a blocker, libdpkg-perl will need to depend on dpkg anyway for the architecture tables. So we can keep Dpkg.pm (and Dpkg/Gettext.pm) there until they can be moved. - Review of all APIs, cleanup, etc. Something I'd like to do pretty soon, after checking if there's anyone using those modules, but before new code starts using them, is to rename: Dpkg/Control.pm → Dpkg/Source/Control.pm Dpkg/Cdata.pm → Dpkg/Control.pm I think the rest of the modules have enough clear names, but it would make sense to check again before we mark them as a public interface. * Merge back debconf support: - Implement invoke hooks. The basic support is there now in 1.15.4, but debconf needs the more advanced one with detailed information of what's going to happen. - Implement db control-path printing. Already in 1.15.4. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Roadmap for the 1.15.x series
On Mon, 07 Sep 2009, Guillem Jover wrote: * Clean up dpkg namespace: - Rename dpkg-ftp as dselect-ftp. I'm the maintainer of this one. Maybe it could be merged in dselect itself, it would make more sense IMO. - Rename dpkg-multicd as dselect-multicd. Maybe we could do the same with this one, given that the goal is to have dselect a separate source package at some point in the future. - Review of all APIs, cleanup, etc. Something I'd like to do pretty soon, after checking if there's anyone using those modules, but before new code starts using them, is to rename: Dpkg/Control.pm → Dpkg/Source/Control.pm Dpkg/Cdata.pm → Dpkg/Control.pm I think the rest of the modules have enough clear names, but it would make sense to check again before we mark them as a public interface. As I said, I'll take care of this part. Give me your comments and I'll take care of them (we should maybe create a wiki page for the API cleanup). I'd rather that you concentrate on the rest (we seem to have a surge of people coming up with patches that need to be reviewed/enhanced and possibly merged :)). Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Roadmap for the 1.15.x series
hi guillem, On Fri, Aug 21, 2009 at 08:20:35AM +0200, Guillem Jover wrote: - Merge back apt-exttracttemplates. - Finish to draft the spec for the debconf integration: http://wiki.debian.org/DpkgDebconfIntegration - Implement invoke hooks. - Implement db control-path printing. - Implement --reconfigure?? * Extend conffile support, merge back ucf: - Store conffiles at install time. http://wiki.debian.org/Teams/Dpkg/Proposals/ConffileDatabase - Support registering configuration files. - Add a new dpkg-conffile to handle conffiles (view, diff, rm, restore, etc). i'm happy to help with both of these, in particular the latter of the two as i think it's something that would be immensely useful to a large portion of our userbase. btw, for the next few months i'm going to have more free time than usual for debian related activities as well, so please let me know what i can do to push this forward. sean signature.asc Description: Digital signature
Re: Roadmap for the 1.15.x series
On Fri, 21 Aug 2009, Guillem Jover wrote:
* New perl modules package [libdpkg-perl]:
- Move Dpkg.pm to libdpkg-perl (= c-rewrite).
- Review of all APIs, cleanup, etc.
- Document perl modules.
- New libdpkg-perl package.
As part of this I also plan some refactoring of how lists of official
fields allowed in {dsc,deb,changes} are managed, some initial ideas
were expressed in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536066#10
Work will also continue to fix dpkg-dev's bugs and some might have a broad
impact:
- we need to find an acceptable way to provide default values to build
flags (CFLAGS and al.), given the last discussion it's probably
by implementing a new dpkg-buildflags tool.
Related to: #489771
- we need to allow usage of build-arch/build-indep rules for the few
packages that would really benefit from it
Tracked in: #229357
- the format of changes files might evolve, two bugs could imply such a
change:
#138409: adding build-environment info in .changes
#65699: let dpkg-buildpackage generate a log file (and possibly upload
it together with the packages)
the latter is less likely if we switch to rebuild on all architectures
(and hence scratch the maintainer uploaded .deb)
Cheers,
--
Raphaël Hertzog
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Roadmap for the 1.15.x series
]] Guillem Jover | * Extend conffile support, merge back ucf: | | - Store conffiles at install time. | http://wiki.debian.org/Teams/Dpkg/Proposals/ConffileDatabase | - Support registering configuration files. Could we add support for registering arbitrary files? Quite a few packages generate files in their postinst script (e.g. byte-compilation of elisp, python), and being able to query for who owns it using dpkg -S would be useful. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Roadmap for the 1.15.x series
Hi, On Fri, 21 Aug 2009, Guillem Jover wrote: Some of those items should be done for squeeze or we'll need to wait for a new release cycle before being able to use them fully (like multiarch and the conffile support), others could get postponed if squeeze gets an early freeze. So please do share yours as well, so that we can send a mail afterwards to the relese team, with the items that we'd really want to get done for squeeze. Support of xz compression would be nice to have so that people could use it in squeeze+1. This concerns .deb and .dsc. I would have liked to be able to update dpkg-source to generate new source formats by default but we need: - that it be deployed on ftp-master (it sucks that ftpmasters are sitting on my patch and don't want to merge it before they finished their sqlalchemy rewrite) - that most of the reported bugs about conversion failure are fixed http://wiki.debian.org/Projects/DebSrc3.0 So it's unlikely that those changes are doable in time. The main trend in my mind is to merge back functionality implemented elsewhere, and ideally an eventual deprecation of some of those other implementations. Is it sorted by priority? Because I doubt that you/we can do everything and you'll have to make choices. * Make dpkg.deb contain only sh and C programs (to help embedded distros, to make it possible to remove perl-base from essential) [c-rewrite]: I might be interested to help here but I'm not sure how much time I can devote to this project. * New perl modules package [libdpkg-perl]: I should really take the primary responsibility for this one. * Extend conffile support, merge back ucf: - Store conffiles at install time. http://wiki.debian.org/Teams/Dpkg/Proposals/ConffileDatabase - Support registering configuration files. - Add a new dpkg-conffile to handle conffiles (view, diff, rm, restore, etc). It would at least be nice to be able to get the work of Sean integrated and maybe be more interactive with him (i.e. review his work regularly) so that he could take the responsibility of implementing more of the related goals. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Roadmap for the 1.15.x series
Hi! Now again with time on my hands, and with the excuse of the release team asking for our plans, I'm sending (after having it been sitting on my computer for some time already) what I'm planning to work on or what I'd like to see done in the near future, ideally during the 1.15.x series which will match the squeeze release cycle. Some of those items should be done for squeeze or we'll need to wait for a new release cycle before being able to use them fully (like multiarch and the conffile support), others could get postponed if squeeze gets an early freeze. So please do share yours as well, so that we can send a mail afterwards to the relese team, with the items that we'd really want to get done for squeeze. For some of these I already have code in my repo on git.hadrons.org which needs final testing and polishing, or have ideas how to do it, so if interested please post on the list first to not overlap on the work. The main trend in my mind is to merge back functionality implemented elsewhere, and ideally an eventual deprecation of some of those other implementations. I'll be sending more detailed mails for some of these items to the list in the following weeks. The stuff inside [] denotes a tag, and the ones inside (= ) are dependencies. The “merge back” development series 1.15.x == * Multiarch support [multiarch]. * Optimization work [optimize]. - Faster and smaller! * Make dpkg.deb contain only sh and C programs (to help embedded distros, to make it possible to remove perl-base from essential) [c-rewrite]: - Move install-info to its own package built from src:info (done). - Rewrite mksplit in C (or merge it into dpkg-split). (= refactor-deb) - Rewrite u-a in C. - Rewrite dpkg-divert and dpkg-statoverride in C. * New dpkg shared library [libdpkg]: - Library API cleanup and general code refactoring. - Try not to inflict setjmp on users by default (provide callbacks). - Provide pluggable allocators to avoid leaking through nfmalloc. - No printing from the library for non-fatal errors, will have to change to return error codes. - Try to make as much as possible reentrant. - Switch to link with shared libraries instead of statically. - New libdpkg0, libdpkg0-dbg and libdpkg-dev packages. * New perl modules package [libdpkg-perl]: - Move Dpkg.pm to libdpkg-perl (= c-rewrite). - Review of all APIs, cleanup, etc. - Document perl modules. - New libdpkg-perl package. * Merge back apt's apt-deb/deb/ and apt-inst/deb/: - Refactor .deb generation. [refactor-deb] - Provide a public interface to access .deb files. (= libdpkg) - Switch apt to use libdpkg. * Merge back debconf support: - Merge back apt-exttracttemplates. - Finish to draft the spec for the debconf integration: http://wiki.debian.org/DpkgDebconfIntegration - Implement invoke hooks. - Implement db control-path printing. - Implement --reconfigure?? * Extend conffile support, merge back ucf: - Store conffiles at install time. http://wiki.debian.org/Teams/Dpkg/Proposals/ConffileDatabase - Support registering configuration files. - Add a new dpkg-conffile to handle conffiles (view, diff, rm, restore, etc). * Merge back debsums: - Generate checksums at build and install time. - Store metadata from .deb at install time. - Add a new dpkg-foo to verify, restore, etc metadata. * Merge back dlocate: - Speed up file searches «dpkg-query -S» (= optimize). * Merge back functionality from dpkg-sig, debsigs-verify, etc: - Refactor .deb generation. [refactor-deb] - Draft a new spec for the signature support inside .deb. - Write a dpkg-sig (or similarly named program) in C. * Merge back dpkg-cross (= mulitarch): - Need a spec for cross multiarch support. - Implement cross multiarch support (if needed). * Move back relevant documentation from policy into dpkg. Russ has mentioned this at some points, should discuss with the policy team. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
