Re: Merging partman
On Tue, May 10, 2005 at 04:25:09PM +0300, Anton Zinoviev wrote:
> 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.
If we kept the different pieces of partman in the same kind of source
tree layout, it would not make any significant difference whether they
were in multiple source packages or in different subdirectories of a
single source package.
> 2. Different partman packages have separate changelogs and this is
> usefull.
True. That could still be maintained if need be, though.
> 3. Different partman packages can have different maintainers.
Is this really an issue? Everything in d-i is team-maintained anyway.
Third-party components could be handled separately.
> 4. It is easier to make third party partman-components (partman-md
> started as such a package)
That's true, but if we kept the existing infrastructure there then that
would still be possible. See my response to 1).
> > > > 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?
Right. In fact the entire structure would stay as it is, just with the
addition of an extra debian/ directory.
> > 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.
Regardless of the version number, apt will "upgrade" a locally installed
package to a version it can see in a repository if the repository
version is >= the locally installed version, not >. This is intentional
behaviour.
> > 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.
I guess it's possible, although *surely* the partitioner would run after
the graphical stage is mounted! After all, an easier-to-handle
partitioner is one of the chief benefits of a graphical installer.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: