Re: 1.2 source archive and packaging issues
>
> [EMAIL PROTECTED] (Erick Branderhorst) writes:
>
> > I don't think it can be done this way, because a lot of makefiles are
> > organized in a way that they require the installer to be root at the
> > moment of installation, or am I misinformed?
> > Perhaps fooling install might be an option?
>
> What do you mean by "require the installer". We don't use "make
> install" for the final install anyway, and if you're worried about the
I use make install in a lot of the packages I maintain because this is the
closest to the mainstream installation. And we want to provide users the
most close to mainstream installation but then better.
[deleted stuff about dummy-installer]
> Reasonable?
Makes a lot of sense to me, can you hack install to do such a thing?
"Unix: 30 definitions of regular expressions living under one roof"
D.E. Knuth
Erick Branderhorst http://www.iaehv.nl/users/branderh/
Re: 1.2 source archive and packaging issues
> I also think that's important. The source packages should be very
> simple, and the source unpacker/packer should be written in a scripting
> language.
tar xzf source-version.tar.gz
mv source.version source.version.orig
tar xzf source-version.tar.gz
cd source.version
zcat ../diff-version-revision.diff.gz | patch
the above lines aren't very difficult but we need to continue with
a few checks IMHO:
"dpkg --status various packages needed for building this package should be
installed ok"
> >From what I've gathered, the rpm format for sources is basically lines
> of text giving control information, followed by a cpio of all the
> gzipped tars. The control field gives commands to do things like
> unpack, build, etc.
> Because we already mandate commands for debian.rules, such complexity
> is not needed. This program (dsource?) would know that it just needs
> to run "debian.rules build" to build, "debian.rules dist" for a
> distribution, etc. The only information in the control field is how to
> unpack.
Not only how to unpack, but also a possibility to download the original
sources (so an URL to the original sources at the original site should be
provided).
The copyright field which comes with rpm might be usefull too, in the
debian source handling approach. We might construct a automatic
/usr/doc/copyright/package file by using this copyright field, the
maintainer information, the url to the original sources, the organization
where the package comes from, the package name the revision name, the
changes made for this revision from debian.Changelog and the contents of
debian.README (which would contain other info than it does right now, only
the copyright info from the original sources).
All this can be translated into some machine created sentences like:
---/usr/doc/copyright/package
This is the Debian Linux prepackaged version of the
distribution. This package -- was put together
by , from the sources, which were obtained from
. The changes for revision are listed below:
The debian specific changes are copyrighted by and put under
the (see /usr/doc/copyright/GPL).
The original sources from are put under the
license.
contents debian.README
---/usr/doc/copyright/package
Additionally we need the possibility to use more than one source (tar.gz)
file. Example is web2c and kpathsea and those big things. So we need more
than one source field and related debian diff field which specify the
patches to be applied at the original sources.
"Unix: 30 definitions of regular expressions living under one roof"
D.E. Knuth
Erick Branderhorst http://www.iaehv.nl/users/branderh/
textutils very big m68k
The textutils package in the Incoming dir on master for the m68k architecture is 1.1 meg big, much bigger than the ?? k under i386. Is this normal or did something went wrong during building, I would like to know because I'm maintaining the thing right now. Can't download it myself, because I'm using a paid line of 14k4, so that would take at least 10 minutes to download the thing. Can someone tell me what happened with this (dpkg --contents text*) "Unix: 30 definitions of regular expressions living under one roof" D.E. Knuth Erick Branderhorst http://www.iaehv.nl/users/branderh/
Bug#4006: Fileutils has /usr/libexec directory
> Package: fileutils > Version: 3.13-2 > > The fileutils package has an empty /usr/libexec directory in the .deb > file. I don't think the FSSTND supports libexec yet, so the directory > should be removed. This dir is standard by make install in gnu packages and didn't see any harm so will not do an update just for removing this dir if you don't mind. If someone can come up with serious problems having this empty dir in the package I'll remove it. Erick
Re: Releases other than by the package maintainert
> (b) that the non-usual-maintainer releases should use a particular > revision format: eg, hello-1.3-8 would become hello-1.3-8.1. Seems very right to me. But I would like to add the following to it. When mainstream is updated, hello-1.3 -> hello-1.4 Non-usual-maintainer updates, hello-1.3-8 -> hello-1.4-0.1 Usual-maintainer updates, hello-1.3-8 -> hello-1.4-1 Usual-maintainer should never use -0 for revisions. And if we agree on this, it should be mandated in the manual. Erick sorry for cc
Bug#3961: 14 character file name limit in zoo
> As zoo comes from DOS I'm not sure if it would be a good idea to > support long filenames. If this is a valid argument for you you might restrict to 8.3 . E
Re: Releases other than by the package maintainert
> > > Non-usual-maintainer updates, hello-1.3-8 -> hello-1.4-0.1 > > > Usual-maintainer updates, hello-1.3-8 -> hello-1.4-1 > > > > > > Usual-maintainer should never use -0 for revisions. > > > And if we agree on this, it should be mandated in the manual. > > > > I think this seems reasonable. I propose to mandate it. > > > > Any objections, considerations ? > > Doesn't this open up the file naming question again. I.e. before we > could say definitively that > > xxx_yyy-zzz.aaa STOP STOP, MY MISTAKE (I meant _) SORRY SORRY, let's continue. Erick
Upstream maintainer in control file
Hi all, I got a request from Jim Meyering (gnu maintainer shellutils, textutils, fileutils etc.) whether or not he could get the bug-reports filed against his packages. I asked Ian J. about this but he couldn't come up with something more than adding the mainstream maintainer in the maintainer field. He said that isn't a good suggestion and I think that it isn't as well. Nevertheless I think that we can solve this by Adding an optional field to the Source part of the new control file: Upstream or Upstream-Maintainer with his/her preferred mail adress and optionally the name of the Maintainer. Sometimes it is difficult to point to the upstream maintainer because it is a large group of people. If this Upstream-Maintainer field exists the bug report system should add an small informative message to the bugreport and sent it to the Upstream-Maintainer. Opinions? Suggestions? Anyone? Ian? Erick.
Re: Source directory name
> Michael> I'd like to name the modules source file modules_2.0.0-8.tar.gz, > Michael> the binary modules_2.0.0-8_i386.deb and the directory in which the > Michael> source is stored IMO should be modules_2.0.0. > As the saying goes: You can't have the pie and eat it. > There are conflicting goals: either we want to make clear that upstream > sources are unaltered (which we agree is a good principle) and therefore name > a source file modules-2.0.tar.gz or we strive for consistency and name it > modules_2.0.0-8.tar.gz which looks as if we have altered the sources. > But I very much like the idea of renaming the directory. After all, it > contains pristine upstream material _plus_ our patches. This is not how I understand the upcoming source handling. I think the only diff made to the original sources is that they unpack in a proper named directory. The patches are applied later but aren't part of the sources files distributed with debian which will be named like hello_1.3.4.orig.tar.gz (IIMNM). Erick
Re: Bruce - fiat required to end discussion on lyx/copyright ?
> All packages in the Debian distribution proper must be freely useable, > modifiable and redistributable in both source and binary form. It must > be possible for anyone to distribute and use modified source code and > their own own compiled binaries, at least when they do so as part of a > Debian distribution. This can't be done with nearly all (la)tex related style files. When one wants to change a (la)tex style an other named copy can be used but the original may not be touched. Do we really want to ditch (la)tex? Erick
Re: devel directory reorg?
> I'd prefer a non-hierarchical reorganization personally. While none of > the ten thousand scripts that run on master should break, I'm sure they > all will. I prefer a non-hierarchical reorganization as well but I suggest that the section directories are listed in one file per Distribution and that all scripts read this file first before doing anything. Adding the name of that one new section will work for all scripts relying on the information about what sections exist. This is kind of similar how the Packages file are right now (in a way). Erick
mfbasfnt 1.0-6 uploaded (Urgency: HIGH)
-BEGIN PGP SIGNED MESSAGE- Date: 23 Aug 96 16:34 UT Format: 1.6 Distribution: unstable Urgency: High Maintainer: Erick Branderhorst <[EMAIL PROTECTED]> Source: mfbasfnt Version: 1.0-6 Binary: mfbasfnt Architecture: all source Description: mfbasfnt: TeX's default fonts and a few others. Changes: Fri Aug 23 18:12:19 1996 Erick Branderhorst <[EMAIL PROTECTED]> . * added black, committee, gray, half, logo, manualfonts, mfbook, slant from ftp.tex.ac.uk /pub/tex/archive/fonts/cm/utilityfonts/ * manfnt.mf was missing in previous relaease causing initex going bezurk when generating .fmt files . Files: 4103e616a218b77baa4bfaa07cfbbf99 202020 tex - mfbasfnt-1.0-6.tar.gz 4fbf5dc5a00b2156305d9a3d5483ceb5 168724 tex standard mfbasfnt_1.0-6_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMh3d3aXl16B8emrRAQE9tAP/UdIgEVJw53lSUsETi/TPOS2DDUleqUvW V2crLkLDdaLCXiTusVAJ0+PIASmnPJzJbcZzGNYBQh+tKwe8x6xm5zm3p8roiiyp jBEVDBQmkf9T4p4qChmATeZYo/vP9SuN8kNC+oMADS9SdCRQLkWS4JHoD6xX0q6/ TfsQM+YkM8A= =sLD3 -END PGP SIGNATURE-
Bug#4447: manfnt.mf missing in mfbasfnt-1.05
> Package: mfbasfnt > Version: 1.0-5 I uploaded 1.0-6 a while ago and it should be fixed it that one.
Re: Do we ever retire packages?
> >Remove them. > > Move them to project/obsolete or some such. Better would be to restructure the archive somehow and name things correctly. I 'm still think something like this would be better: stable/ /admin /base /comm ... stable-extra/ /contrib /non-free -> .../non-free /obsolete /experimental /and other names which don't fit in the above unstable/ /admin /base /comm ... unstable-extra/ /contrib /non-free -> .../non-free /obsolete /experimental /and other names which don't fit in the above This will leave us two main entries for all the packages in a distribution. The problem with stable and unstable non-free/contrib packages will disappear (they will be included in the releases approach we are following). non-free and contrib will get the same status as the other sections like base, admin and comm &c. This will make the structure far more consistent. Erick > > -- > Christopher J. Fearnley|Linux/Internet Consulting > [EMAIL PROTECTED], [EMAIL PROTECTED] |UNIX SIG Leader at PACS > http://www.netaxs.com/~cjf |(Philadelphia Area Computer Society) > ftp://ftp.netaxs.com/people/cjf|Design Science Revolutionary > "Dare to be Naive" -- Bucky Fuller |Explorer in Universe > > >
Bug#4447: manfnt.mf missing in mfbasfnt-1.05u
> > Package: mfbasfnt > > Version: 1.0-5 > > I uploaded 1.0-6 a while ago and it should be fixed it that one. Sorry I noticed that it was rejected because of a bad checksum. Currently uploading 1.0-7. Erick
