Re: apt

[Jason Gunthorpe <jgg@ualberta.ca>]

On Fri, 1 Sep 2000, Alfredo Kengi Kojima wrote:

> Many of the files have probably gone through some reformating,
> as I use an auto-indenting editor. I promise to make a pretty
> patch that will suit your coding style tastes, when I send you
> the definitive diff :)

Donno, when I made my diff it was mostly fine..
 
> > * Build Dir:
> >    -CPPFLAGS+= -I$(INCLUDE) -I/usr/include/rpm
> >    +CPPFLAGS+= -I$(INCLUDE)
> >  Eek! nononono, use #include <rpm/foo.h>, do not do that. Especially 
> >  do not do that in the file where you have done that. 

> I can't do that because the rpm header files do #include "foo.h"
> That's rpmlib's fault, I hate it.

*barf* File a bug in Debian's BTS :| My usual way to fix crap like this is
with configure magic..
 
> Because I can't ship a dynamically linked application that
> will require many libraries that are probably not installed
> (or worse, are in the wrong version) in the machine of many 
> of our potential users. 
> But of course, that's another thing that needs cleaning
> before a public release.

Well, why would you do that during testing? You can build a static version
at any time with some options to make.. It is much easier to compile/debug
when you use shared libraries.
 
> >   + Is not C++
> 
> Why is that a problem?

I prefer to only require a single compiler.. Also it sounds like the bit
of that directory you are keeping should be moved into the apt-ftparchive
tool (See cvs).
 
> > -   if (1) {
> > -      ConectivaFactory *factory = new ConectivaFactory;
> > -   } else {
> > -      DebianFactory *factory = new DebianFactory;
> > -   }
> > 
> >   + Heh, that's just bad style :>
 
> Oh, really? :P 

Yeah, there is a great way with C++ to have the linker build those kind of
things for you.

> > 'distro' is not a name I like. I would prefer a name like environment, or
> > system, or something like that.

> Ok, _system is fine for me.

Great!
 
> > putting dep checking and version checking in 'distro' is something I
> > *hate*. I think it is much more appropriate to create a new field in the
 
> Yes, I know. But that's yet another temporary kluge. 
> Btw, if you see something horrible, you can assume it's temporary.
> I think I don't code THAT badly :)

Well, this particularly is a big style thing, there are reasons to do it
either way..
 
> > Basically, if you make me a nice patch that does the _distro thing with a
> > nicer name and makes deb use it then I will apply it and maintain it for
> > you. If you want, I would even build something based on what you have now,
> > but you'd have to wait a good while :|
 
> That's good, thank you. I think the delay is acceptable by me,
> if a temporary fork is acceptable by you. :)

K.. I'll see what my schedual looks like this month..
  
> The stuff in the RPM directory is still under heavy testing
> and development, so it will change a lot. You will probably
> get lots of trouble in the initial run. Some of them will
> be legitimate dependency problems, due to a few glitches
> during isntallation. Some will be due to possible packaging
> problems and some due to possible bugs in apt. But we're working
> to get these probs fixed.

Okay. My main concern is mostly that I need to be able to see and use this
code to make sure it works the way I intended APT to work.. I'm pretty big
on style, I expect a certain 'feel' from my software.
 
> Anyway, Conectiva 5.1 is available through ftp at:
> ftp://ftp.conectiva.com.br/pub/conectiva/5.1

Great, I have lots of bandwidth and a spare partition, I'll give it a
spin.

> > 
> > Please base your work off CVS apt, the 'aliencode' branch which will
> > become APT 0.5.0 eventually, that is where I will apply your patches.
> >
> 
> Ok. Are there any significant changes since apt-0.3.19 to current cvs?

Hmmm.. Yes, but they are laregely still seperate from the code base you
are worried about.
 
> The file dependencies are fully handled in a rather simple way.
> The code just converts the file dependencies into normal dependencies,
> by going through the list of packages twice. One to make a list
> of files in the Depends tag of each package and another to
> put each of these files in the Provides tag of each package
> that contains those files.

Interesting.. do you do this globally over all package files? I actually
suggested something like this to msw at OLS... 

> The pkglist for us will be a lot larger than for debian,
> since it includes the file list for each package, but I consider
> that to be acceptable.

You know, if you control the format of the index files you can probably
reduce the overhead of this by packing the filename information.
 
> Not many, as you can see. In the pov of apt, file depencies
> are nothing but a dependency that starts with a / character.
> We just needed to search who provides these files by hand
> and put them in the provides list of the appropriate packages.
> Once that's done everything is 100% transparent to apt.

Sneaky.. That would work quite nicely with the APT guis too.
 
> Since all distribution specific code is being abstracted
> and totally separated from the main code, it will be possible
> to select which distribution apt will support at run time,
> by doing some simple checks to see if you run Debian,
> Conectiva or whatever. That's the elegant solution, imho.

Both must be an option.. I will want to have both versions in my build
tree for testing, but Debian packages can't link to librpm.

This can be done trivally with some make file magic and global
constructors.

Jason