Re: [SFE-devel] question/query your opintions: storing spec files in project subdirectories

[Milan J. <mil...@or...>]

Hi Thomas,

Thomas Wagner píše v po 13. 06. 2011 v 21:45 +0200:
> Hi all, thanks all,
> 
> so the remaining question is, when we should move back the files
> from those subdirectories:
> 
> gmpc-plugins haskell perl python
> 
> Any day is okay for you? It will put a bit load on the next
> svn checkout for all users.
> 

for me any date is OK.

> For haskell as an exception, Alex suggested on IRC to just leave
> them there, until a maintainer is willing to work on them. With
> haskell it is the same as with perl/CPAN and php-pear that the
> interpreter does self-install new modules/scripts/libs which is
> at minimum interfering with the package manager of the OS.
> The (semi)automatic install mechanisms should be enhanced to
> register theyr files with the package manager or just generate
> regular packages and install them immediately.
> 

I agree.

Thank you

Milan

> Any other ideas or point we should have a close inspection
> before we do the move ?
> 
> Thanks much for contributing,
> Thomas
> 
> PS: We'll have to keep an eye on the one undeleted SFEperl-uri.spec 
> in the root directory
> 
> On Sun, Jun 12, 2011 at 08:58:37PM +0200, Milan Jurik wrote:
> > Hi Alex,
> > 
> > I would welcome it as the current status complicates my automated build
> > environment.
> > 
> > I understand reasons for your effort but without more maintainers and
> > somebody who will look over all commits it can create more duplicities.
> > 
> > Best regards,
> > 
> > Milan
> > 
> > Alex Viskovatoff píše v ne 12. 06. 2011 v 13:43 -0400:
> > > Those subdirectories were created in a misguided attempt to bring some
> > > order to how specs are arranged at the SFE repository. Now that the
> > > OpenIndiana project is using an XML file to represent its view of SFE,
> > > which allows packages that have been built to appear in an orderly way
> > > in Package Manager, all the specs other than the ones in encumbered/
> > > being in the same directory is no longer an issue.
> > > 
> > > Therefore, if any automated procedures have been impacted adversely by
> > > the new subdirectories, by all means get rid of them and go back to how
> > > things were before.
> > > 
> > > On Sun, 2011-06-05 at 20:10 +0200, Thomas Wagner wrote:
> > > > Hi all!
> > > > 
> > > > The idea appeared to store collections of spec files into subdirectories
> > > > in our spec-files-extra repository.
> > > > 
> > > > 
> > > > Examples:  perl-modules, gmpc-plugins, haskel extensions, and others
> > > > 
> > > > 
> > > > Quick questions / asking for your opinions:
> > > > 
> > > >  * should we do this in general for (some) more projects / thematicly
> > > >    similar spec files
> > > > 
> > > >  * should we more keep the old practise of *only* having experimental/
> > > >    and archive/, all the rest is sitting in one "namespace" in the
> > > >    root directory of the svn repo.
> > > >    (as well for patches, but base-specs/ and include/ are not subject)
> > > > 
> > > >  * impact on the "overview" for finding random spec files
> > > >    a) novice users
> > > >    b) old-timers
> > > >    c) extra-terrestrials  *)
> > > > 
> > > >  * impact on (avoiding) duplicate files (and in extended example: patches as well)
> > > > 
> > > >  * impact on automated build servers (dynamicly changed logic of build scripts)
> > > > 
> > > >  * impact on the automatic finding of spec files by pkgtool and the
> > > >    ".pkgtoolrc" setting for specdirs  (and in extended example: patchdirs)
> > > > 
> > > >  * possible duplicate filenames and which ones get found first / which ones
> > > >    ignored
> > > > 
> > > >  * the need of having pkgtool/pkgbuild patched (in extended example to
> > > >    accept path components in a %Patch1 this234/this-01-magicpatch.diff)
> > > > 
> > > > 
> > > > Some of you might find separate sub-directories for spec files (and patches)
> > > > usefull, others might not.
> > > > 
> > > > 
> > > > Thanks much for your quick opinions. To be open, my very personal preference
> > > > is hopefully not expressed here. I'll try instead to write a follow up after 
> > > > other SFE maintainers have expressed theyrs. I don't want to influence the
> > > > outcomings more then I already did with the wording of the above lines.
> > > > 
> > > > Thanks much for taking some few minutes of your valuable time!
> > > > 
> > > > Cheers
> > > > Thomas
> > > > 
> > > > *) I'm sorry, I couldn't resist. I really hope on getting your opinions
> > > >    on the other questions
> > > 
> > > 
> > > ------------------------------------------------------------------------------
> > > EditLive Enterprise is the world's most technically advanced content
> > > authoring tool. Experience the power of Track Changes, Inline Image
> > > Editing and ensure content is compliant with Accessibility Checking.
> > > http://p.sf.net/sfu/ephox-dev2dev
> > > _________________________________________________________________
> > > SFE-devel mailing list - Pkg...@li...
> > > http://pkgbuild.wiki.sourceforge.net/SFE
> > > https://lists.sourceforge.net/lists/listinfo/pkgbuild-sfe-devel
> > 
> > 
>