Re: Merging partman
On Tue, May 10, 2005 at 12:33:22PM +0100, Colin Watson wrote:
> On Mon, May 09, 2005 at 09:16:43PM -0400, Joey Hess wrote:
> > Colin Watson wrote:
>
> > > I understand why partman is broken down into lots of *binary* udebs, and
> > > obviously we can't change that without having a serious effect on lowmem
> > > installations and so on. However, I don't think there's really a good
> > > reason any more why it shouldn't be a single source package.
The benefits of the many source packages instead of only one are: 1. It
is easier for the developers to add a new component to partman - they
can simply copy an existing package and change whatever they want. 2.
Different partman packages have separate changelogs and this is usefull.
3. Different partman packages can have different maintainers. 4. It is
easier to make third party partman-components (partman-md started as
such a package)
> > > Would anyone (especially Anton) object to me merging the whole lot
> > > together? I was basically thinking of creating packages/partman/debian/
> > > and leaving the other directories more or less as they are now, although
> > > some further rationalisation there might make sense later.
Actually in the very first (pre-CVS) versions of partman I did exactly
this. I suppose that the partman-* subdirectories will still have their
own debian directories and changelogs?
> There's also the question of versioning. Conveniently, partman itself
> currently has a higher version number than partman-*, so the merged
> source package could just start out at 65 or 70 or whatever.
The versions of the partman-* packages are not related one to other so
the new non-d-i package can also have unrelated version number. However
do not use versions that are plain numbers without dot. I think at
least some time ago apt had a bug that caused such a package to be
always upgraded even when the apt-repository doesn't contain a newer
version than the already installed.
> One other issue is that lots of partman code hardcodes
> /lib/partman/definitions.sh and similar, which will have to move to
> /usr/lib for FHS-compliance in a .deb. Maybe we should just move this in
> the installer too, and leave a symlink behind.
I haven't used the /usr hierarchy in partman intentionaly. I observed
that many other installers have a simple initrd file system that leaves
/usr alone and then they mount on /usr (from CD) a reacher file system
with X server in order to run the graphical stage of the installer. I
thought that in future we could do the same.
Anton Zinoviev
Reply to: