Roadmap for the 1.15.x series

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Roadmap for the 1.15.x series

Guillem Jover
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for the 1.15.x series

Tollef Fog Heen
]] 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for the 1.15.x series

Raphael Hertzog-3
In reply to this post by Guillem Jover
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for the 1.15.x series

Guillem Jover
In reply to this post by Guillem Jover
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for the 1.15.x series

Raphael Hertzog-3
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for the 1.15.x series

sean finney
In reply to this post by Guillem Jover
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 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for the 1.15.x series

Raphael Hertzog-3
In reply to this post by Guillem Jover
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for the 1.15.x series

Guillem Jover
In reply to this post by sean finney
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for the 1.15.x series

Guillem Jover
In reply to this post by Raphael Hertzog-3
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for the 1.15.x series

Guillem Jover
In reply to this post by Tollef Fog Heen
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for the 1.15.x series

Raphael Hertzog-3
In reply to this post by Guillem Jover
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for the 1.15.x series

Joey Schulze
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for the 1.15.x series

Raphael Hertzog-3
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for the 1.15.x series

Joey Schulze
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for the 1.15.x series

madcoder (Bugzilla)
In reply to this post by Raphael Hertzog-3
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
··O                                                [hidden email]
OOO                                                http://www.madism.org

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for the 1.15.x series

Raphael Hertzog-3
In reply to this post by Joey Schulze
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for the 1.15.x series

Guillem Jover
In reply to this post by Guillem Jover
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]